Hosted, Embedded, or Your Own Form

Notes

For a first card payment, you are choosing how much of the payment page you own. A hosted checkout redirects the customer to the payment provider’s page, so the provider collects the card details. An embedded element places provider-owned card-entry UI inside your page, usually in an iframe, so your site controls the surrounding experience but not the raw card fields. Your own form means you build the card inputs yourself and send card data onward, which gives maximum control but also maximum responsibility.

The practical mental model is: who touches the card number? With hosted checkout, your server creates a payment or checkout session and the browser leaves your site to pay. With embedded elements, your site displays the payment flow, but sensitive card data goes directly from the provider-controlled component to the provider. With your own card form, your JavaScript and infrastructure handle sensitive payment data, even if only briefly, so you have stepped into a much larger compliance scope.

The common misconception is that PCI compliance only matters if you store card numbers. That is wrong. PCI scope is also about whether your systems can see, transmit, or affect the security of cardholder data. Hosted checkout usually leads to the simplest PCI questionnaire. Embedded provider elements usually keep you in a reduced questionnaire because raw card data bypasses your systems. A fully custom card form generally increases the questionnaire burden and may require stronger controls, audits, and security processes.

After this lesson, you should be able to make a product-and-risk tradeoff. Choose hosted checkout when speed, security, and low compliance work matter most. Choose embedded elements when you need a more integrated user experience while still keeping card data mostly out of your systems. Avoid your own card form unless the business truly needs that control and is prepared for the extra PCI responsibility.