Every online store has to decide who builds the screen where the customer pays. With a hosted checkout, your payment provider or orchestrator builds it: you create a session from your backend and either redirect the customer to the provider’s page or embed the provider’s form in yours. With a direct API integration, you build the screen yourself and call the payment API from your own code.
The choice affects four things: how much of your estate is in PCI DSS scope, how long the build takes and who maintains it, how much control you have over the experience, and how quickly you can add payment methods in new markets.
What is a hosted checkout?
A hosted checkout is a payment page or form served by the provider. The customer’s card details go from their browser straight to the provider, and your systems receive a result, never the card number. Stripe, for example, offers a full prebuilt payment page you redirect to or embed, and an embedded form. Orchestrators offer the same idea in front of many providers: Omno’s hosted checkout shows cards, local methods and crypto, with routing running behind it.
There are two common shapes. A full redirect sends the customer to the provider’s page and back. An embedded form keeps the customer on your page with the provider’s form inside an iframe. Some providers also offer hosted fields: only the card number and security code are served by the provider, inside a form you otherwise build, as Spreedly’s iFrame does.
What is a direct API integration?
With a direct integration, you design the checkout and call the payment API from your frontend and backend. Stripe’s guidance for its lower-level Payment Intents API is that it suits businesses that want to own every part of their checkout, and that it requires significantly more code and ongoing maintenance than its prebuilt checkout. Adyen describes a similar spread: a sessions flow with one server request and light effort, and an advanced flow with three server requests in which your code handles redirects and additional actions on both client and server.
If your direct integration posts raw card data to your own servers, your PCI scope grows sharply. Many teams therefore combine their own design with the provider’s hosted card fields, which keeps card numbers off their servers while leaving the rest of the page under their control.
How does PCI DSS scope differ?
PCI DSS sets out several self-assessment questionnaires. As Davis Wright Tremaine summarises PCI SSC’s guidance, SAQ A is for e-commerce merchants that fully outsource card processing to a PCI DSS compliant provider, including full redirects and provider iframes; merchants whose own pages or servers take part in handling payment data generally need SAQ A-EP, and those that store, process or transmit card data need the full SAQ D.
PCI SSC FAQ 1588 adds one condition for embedded forms: a merchant whose page includes a provider’s embedded payment form must confirm the page is protected from script attacks, either with its own controls or with confirmation from the provider. A full redirect does not carry that requirement. Your acquirer or the card brands decide which questionnaire applies to you, so describe the real integration to them.
Where is a hosted checkout stronger?
Speed to launch. A session request from your backend and a script or redirect on the frontend is a short project. Stripe recommends its prebuilt checkout for most integrations for that reason.
PCI scope. Card data never reaches your servers, which usually means the lightest questionnaire.
New methods without new code. In a hosted checkout, a local method appears once it is enabled. With a direct API, each method’s fields, redirects and status handling are code you write and test.
3DS and redirects. Authentication challenges, bank redirects and wallet flows are handled inside the hosted flow.
Where is a direct API integration stronger?
Total control of the experience. Every field, step and message is yours, which matters when checkout is a core product surface or part of a larger flow such as onboarding or a marketplace basket.
Owning checkout state. Discounts, tax, subscriptions and currency logic live in your code, in the order you want.
No dependency on the provider’s layout. Your checkout does not change when the provider redesigns its page.
Backend-only flows. Some flows have no customer screen at all, such as scheduled payouts or payment links on invoices. Those are direct API work by nature.
How do you combine them?
Most merchants that sell across several countries end up with a mix:
- Cards through a hosted checkout or hosted fields, so card data stays with the provider.
- Local methods, crypto and payouts through backend API calls where you want your own interface, because no card data is involved.
- One source of truth for status: the webhook, not the redirect back to your site, as our webhooks guide explains.
In Omno, that split is the hosted checkout or Card Fields for cards, and Direct Links for local method, wallet and crypto payments and payouts from your own systems, with no Omno payment page.
Who should choose which?
A hosted checkout fits if:
- You sell in many markets and need many local methods quickly.
- Your payments or engineering team is small.
- Keeping card data and PCI scope away from your systems is a priority.
A direct API integration fits if:
- Checkout is a core part of your product and design control matters.
- You can staff the build, testing and maintenance of every method you offer.
- You can meet the PCI requirements of your integration, or you use hosted card fields inside your own page.
How we compared
Omno offers a hosted checkout, and Card Fields and Direct Links for merchants who build their own, so we have an interest in this question but not in one answer. The table compares the two approaches, not specific products, and individual providers vary. Each row links to the provider guidance or PCI material it rests on: PCI SSC’s FAQ, a law-firm summary of PCI SSC guidance, and Stripe’s, Adyen’s and Spreedly’s own integration documentation.