Checkout integration models explained: hosted, embedded, and API compared

Checkout integration models get treated as a single choice: hosted, embedded, or API. In practice, merchants running the strongest approval rates rarely make that choice once — they make it three times, once per payment flow, because PCI DSS scope⁠, conversion risk, and engineering capacity pull in different directions depending on what's being sold, to whom, and on which device.

A hosted payment page is the fastest route to accepting card payments and the surest way to avoid the heaviest compliance tier. An embedded checkout keeps the buyer on-brand. A direct API integration gives the payment team full control over the experience, along with the full weight of the compliance scope that comes with ownership. None of these is the 'right' model in isolation. Each is right for a specific flow, and knowing which is which is what separates a checkout architecture from a checkout guess.

I'll break down what each model costs to build, what the conversion data actually supports, and a framework for deciding which model belongs where.

How checkout integration models work: hosted, embedded, and API compared

Merchants generally choose between three payment integration options.

Hosted checkout

Hosted checkout redirects the buyer to a payment provider-hosted page, or opens it in a modal, so payment data never touches the merchant's own servers or scripts. The merchant creates a session, sends the buyer to a generated URL, and the provider handles the rest — rendering the form, capturing the card, confirming the payment.

• PCI impact: the entire payment surface lives on the provider's domain, so the merchant's own infrastructure is largely out of scope. Typically qualifies for Self-Assessment Questionnaire (SAQ) A: 24 questions.
• Build time: hours, not days — most providers get a hosted checkout live from a dashboard, with little more than configuration.
• Tradeoff: the buyer sees the provider's page, not the merchant's. Layout, language, and payment-method order are usually limited to the provider's template.
• Best fit: donations, one-off digital purchases, low-consideration purchases, or any merchant without a dedicated payments engineering function.

Embedded checkout

Embedded checkout keeps the buyer on the merchant's domain, while the payment fields themselves run inside an iframe or a client-side SDK component supplied by the provider. The merchant owns the page around the form — headers, product details, order summary — while the provider's component renders the card fields and tokenizes the data before it reaches the merchant's backend.

• PCI impact: the merchant's page controls what surrounds the payment form (and often the confirmation step), which pulls that page partway into scope even though the sensitive fields stay isolated. Lands on SAQ A-EP.
• Build time: days to weeks — real front-end integration work, device testing, and handling the provider's event callbacks.
• Tradeoff: more build effort than hosted, in exchange for the buyer never leaving the merchant's site.
• Best fit: subscriptions, goods with a high average order value (AOV), gaming platforms — any flow where a jarring redirect costs trust.

Types of embedded checkout

Under the label ‘embedded checkout’ sit several different implementations, each with its own PCI footprint and build effort:

• Full embedded hosted checkout (checkout in an iframe): the provider's complete, ready-made checkout page loads inside an iframe on the merchant's own domain instead of opening in a new tab or redirecting away.
• Drop-in checkout component: a prebuilt JavaScript component that mounts directly into the merchant's page, rendering the full payment UI without an iframe boundary. It predates today's iframe-based approaches but is still found across the market.
• Hosted fields: individual, isolated iframes for each sensitive input — card number, expiry, CVV⁠ — that a non-PCI DSS merchant drops into a checkout page it otherwise builds and controls end-to-end. Card data never touches the merchant's own servers or scripts.
• Payment elements, or modular components: a broader version of hosted fields. Instead of covering card inputs alone, individually embeddable components can also cover wallets, alternative payment methods, billing details, and payment-method selection, each mounted and styled independently.
• In-app or mobile-embedded checkout: the same embedded logic applied within a mobile app via a WebView, native SDK, or hybrid flow. The mechanics mirror the web pattern, but mobile adds its own constraints — deep links, app-switch behavior, 3D Secure⁠ challenges, and returning the buyer to the app after an Apple Pay or Google Pay payment.

Direct, or API checkout

Direct API integration removes the provider's rendered UI entirely. The merchant builds the payment form from scratch and calls the provider's API directly to create and confirm the payment, meaning card data can transit the merchant's own systems before tokenization happens.

• PCI impact: full SAQ D — the merchant's own systems handle cardholder data directly, not just the page around a provider's component.
• Build time: weeks to months, and tax, discounts, shipping, and currency conversion must be built separately, since the API only models the payment step itself.
• What it buys: a fully custom UI, full A/B testing control, and support for complex logic — split payments, escrow-style payouts, native mobile SDKs — that hosted and embedded aren't built to handle.
• Best fit: high-volume merchants and native mobile apps that graduate into this once the engineering cost is justified by scale.

Decision framework: matching the model to your situation

Six variables decide which model fits a given flow, and they rarely all point the same direction:

• PCI maturity: a payment team with an in-house security function can absorb SAQ A-EP or D's extra controls; a lean team without one should default to hosted wherever the flow allows it.
• Time-to-market: hosted checkout ships in hours via most providers' dashboards; API-direct integrations can take weeks or months of engineering work.
• Brand control: high-consideration purchases, such as subscriptions, high-AOV goods, or gaming platforms, lose more to a jarring redirect than low-consideration ones, such as donations or one-off digital goods.
• Device and surface: native mobile apps are generally better served by SDK-based field tokenization than by loading a payment page inside a WebView. This pushes mobile-native flows toward embedded or API models.
• Risk profile: high-risk verticals, such as iGaming, crypto, or forex, often need the routing flexibility that only a direct API integration or an orchestration layer provides, since a single PSP relationship rarely survives sustained high-risk volume.
• Volume and negotiating leverage: at low volume, a hosted page from any compliant provider is more than adequate; at scale, the fee and approval-rate gains from a direct, tokenized integration typically outweigh the extra compliance overhead.

No single flow needs all six to point toward one model. That is precisely why most scaled merchants stop trying to pick one.

Why checkout customization matters beyond branding

Brand control usually gets framed as a look-and-feel question — logo, colors, fonts. That undersells what customization actually does to performance.

A checkout that shows the wrong currency, the wrong local payment methods, or a card-first layout to a market that prefers wallets is actively working against conversion. The mix of payment methods a buyer sees, the order they appear in, and whether the page reflects their market or device all shape whether they finish the purchase, and none of that is solved by the integration model alone.

This is where customization and integration model intersect. A merchant running the same hosted page across ten markets is making a decision, whether they realize it or not, to show every buyer the same payment method order and the same layout regardless of what actually converts in that market. Embedded and API checkouts technically remove that constraint, but only if someone on the team has the time to build and maintain market-specific variants — which is exactly the kind of ongoing engineering cost the earlier cost breakdown doesn't fully capture.

The practical fix is decoupling checkout customization from engineering effort entirely.

🎨Test-drive our Checkout builder

Configure, and launch fully branded checkout flows — for every merchant, market, and use case — without touching code or waiting on a developer.

Learn more

How Corefy's Checkout brings hosted, embedded, and API together

On Corefy, these three models are not three separate integrations to build and maintain. They're configurations of one Checkout. Switching a flow from hosted to embedded, or to a fully custom UI, means flipping a setting.

• Launch hosted in minutes: simply create a Checkout⁠ and you're live, no extra configuration required.
• Go embedded when you need it: turn on iframe support and whitelist your domain under Security preferences, and the same Checkout sits inside your own page, with confirmation staying on-page too, so the customer never leaves your site.
• Go fully custom with Hosted fields: build your own payment form while the sensitive card fields stay isolated in secure, Corefy-managed iframes, giving you full design control without inheriting the heaviest PCI scope.
• Go direct with Host-to-Host: if your team already owns full PCI DSS compliance and has built its own checkout UI in-house, skip the rendered UI entirely and integrate host-to-host — your servers call Corefy's API directly to create and confirm payments, the same Direct, or API checkout path described earlier, without adopting any of Corefy's front-end components.

Whichever presentation you choose, the backend underneath doesn't change. The same routing and cascading rules apply everywhere. Webhooks drive order status, so fulfillment never depends on what the customer's browser does. Wallets, saved cards for one-click repeat payments, and automatic retries, all part of the same Checkout method settings, work the same way across all three. That's the real value: a payment team can run hosted, embedded, and a custom UI side by side, for different flows, without three integration projects, compliance reviews, or codebases to maintain.