Hosted vs embedded checkout: which should you use?

With a hosted checkout, your customer is sent to a payment page run by your gateway or billing provider; with an embedded checkout, the payment form appears inside your own website, usually in an iframe or a pop-up supplied by the gateway. Hosted checkout is faster to launch and keeps your PCI DSS scope smallest, while embedded checkout keeps customers on your site at the cost of more integration and security work on your side.

Neither is "right" for everyone. This comparison covers what really differs and helps you pick.

The three common patterns

The third pattern puts your systems fully in scope for PCI DSS and is rarely sensible for small and mid-size businesses. The real choice for most is between hosted and embedded.

Hosted vs embedded checkout on security and PCI DSS

PCI DSS (version 4.0.1 is current) applies to anyone who accepts cards. The key question is how much of your own infrastructure can affect card data.

Hosted redirect. Card details are entered on the provider's page, not yours. Your site only sends the customer there and receives the result. This is usually the smallest scope.

Embedded iframe. Card details are still entered into the provider's frame, but that frame sits on your page. If an attacker could inject malicious script into your page, they could potentially overlay or tamper with the payment experience.

This is why the January 2025 update to SAQ A matters. Effective 31 March 2025, the PCI Security Standards Council removed two script-related requirements (6.4.3 and 11.6.1) from SAQ A, but added an eligibility criterion: the merchant must confirm their site is not susceptible to attacks from scripts that could affect the e-commerce system. Merchants who embed a payment iframe need to confirm the protections they have in place, while full-redirect merchants are less affected. Check the details and confirm your eligibility with your acquirer via the PCI Security Standards Council.

In practice, for embedded checkout that means:

• Keep third-party scripts on checkout pages to a minimum
• Use a Content Security Policy and Subresource Integrity where you can
• Control who can change your site's code and tags
• Monitor for unexpected changes to checkout pages

Customer experience

Hosted checkout strengths

• A consistent, tested page maintained by a payments specialist
• Payment methods, 3D Secure and wallets are handled for you
• Easy to reuse for payment links, invoices and email

Hosted checkout weaknesses

• The domain change can feel abrupt if the page doesn't look like your brand
• Less control over layout and flow

Embedded checkout strengths

• Customers stay on your site throughout
• Fits naturally into single-page apps and custom flows

Embedded checkout weaknesses

• More ways for things to break on mobile (frame sizing, pop-up blockers, the 3D Secure redirect)
• You're responsible for more of the page's security

A hosted page that carries your branding closes most of the experience gap. Customers are used to being redirected to pay; what makes them hesitate is a page that doesn't look like the business they were buying from. See branded checkout page design for how to get this right.

Developer effort

With either approach, never trust the browser's "success" redirect on its own. Confirm the payment with a signed server-to-server webhook, and ideally re-check the status with the gateway API before you fulfil the order. Our payment webhooks best practices guide explains how.

Which to choose

Choose hosted checkout if:

• You're a small or growing business without dedicated security staff
• You also send payment links or invoices and want one consistent payment page
• You want to add payment methods or gateways without front-end work
• You want the simplest compliance position

Choose embedded checkout if:

• Staying on-page is central to your product experience (for example, inside a web app)
• You have developers who can maintain the integration and the page security it requires
• Your gateway provides a well-supported embedded component

Consider both if you run a web app with an in-app upgrade flow (embedded) and also send invoices and renewal links (hosted).

A practical middle path

Many businesses use a hosted checkout page that looks and feels like their own site: same logo, colours, fonts and product summary, served on a checkout page created for each order through an API. It keeps the compliance benefits of hosted checkout while reducing the "where am I?" moment that costs conversions.

How CentraPoint helps

CentraPoint provides hosted checkout pages that you design and brand yourself, created per order through checkout sessions in the REST API. The payment itself is completed through the gateways you connect, such as PayFast, Paystack or Peach Payments, and CentraPoint confirms payments through verified inbound webhooks that are signature-checked and re-verified server-side. The developer docs cover checkout sessions in detail.

Frequently asked questions

Is a hosted payment page more secure than an embedded form?

Generally it keeps more of the risk with the provider, because card details are entered entirely on the provider's page and domain. Embedded forms can be secure too, but your own site's security plays a bigger role.

Does an iframe checkout qualify for SAQ A?

It can, but since the January 2025 SAQ A update the merchant must confirm their site isn't susceptible to script attacks affecting the payment page. Confirm your eligibility with your acquirer.

Do customers abandon when redirected to a hosted page?

A redirect to an unfamiliar, unbranded page can cause hesitation. A hosted page with your branding and a clear order summary reduces that risk considerably.

Can I switch from hosted to embedded later?

Yes. Many businesses start hosted to launch quickly and add an embedded flow later for specific journeys, keeping the hosted page for payment links and invoices.