Hosted, Embedded and API Checkout: Which Should You Use?

When you integrate online payments into a website or app, you have to decide how much of the checkout experience you build yourself and how much your payments provider handles for you. The three common models are a hosted payment page, an embedded checkout, and a direct API integration.

The choice affects development effort, how much control you have over the customer experience, and — importantly — how much of the PCI DSS security burden falls on your business. This page compares the three so you can pick the right starting point.

The three models compared

What is a hosted checkout?

With a hosted checkout, the customer is redirected from your website to a secure payment page operated by your provider. They complete the payment there — card details, 3-D Secure verification, alternative methods like instant EFT or PayShap — and are then returned to your site with the result.

Advantages:

• Fastest to integrate; often just a redirect and a return URL
• Card data never touches your servers, keeping your PCI scope minimal
• The provider maintains the page, so new payment methods and security updates arrive without work on your side

Trade-offs:

• The customer briefly leaves your site, which you have less control over
• Branding and layout options are limited to what the provider allows

Hosted checkout is the right default for most small and medium businesses, and it is the same model that powers payment links — a payment link is essentially a hosted checkout page reachable by URL.

What is an embedded checkout?

Embedded checkout keeps the customer on your website while the sensitive fields — card number, expiry, CVV — are rendered inside secure components (often iframes) served by your provider. To the customer it looks like a seamless part of your page, but the card data flows directly to the provider and never passes through your systems.

Advantages:

• A seamless, on-brand experience with no redirect
• PCI scope stays small because you never handle raw card data
• You control the surrounding page: order summary, upsells, layout

Trade-offs:

• More development work than a redirect, including handling callbacks and error states
• You are responsible for the page around the components, so front-end quality matters

Embedded checkout suits businesses that care about conversion and brand consistency and have some development capacity.

What is a direct API integration?

With a direct API integration you build the entire checkout yourself and communicate with the provider's API server-to-server. This gives full control — custom flows, saved cards, complex order logic — but if raw card details pass through your servers, your business falls into the most demanding PCI DSS compliance levels, which requires audits and significant security investment.

For this reason, pure direct-API card integrations are rare outside large enterprises. Most "API" integrations in practice combine server-side APIs for orders, refunds and reporting with tokenised or component-based capture of the card details, keeping compliance manageable. For a broader look at integration approaches, see payment integration models.

How do I get notified of payment results?

Whichever model you choose, do not rely only on the customer's browser returning to your success page — connections drop and customers close tabs. Use server-to-server notifications, called webhooks, as the source of truth for payment outcomes. See webhooks and callbacks.

Which one should you choose?

• No developers, or you want to launch this week: hosted checkout or payment links.
• A development team and a conversion-focused website: embedded checkout.
• Complex, high-volume requirements and dedicated engineering: API-led integration with tokenised card capture.

Kwik supports hosted checkout out of the box, so you can start simple and move to a deeper integration as your volumes grow. For the bigger picture of going live with online payments, read how do I accept payments online, or return to the accepting payments hub.