.png)
TL;DR
Every payment gateway has to answer one question at the moment a buyer pays: where does the card data get entered, and who is responsible for it. There are two answers. They look the same to a buyer. They are very different for your business.
Get this choice right and you match the trade-offs to what you actually need. Get it wrong and you either give up control you wanted or take on compliance weight you did not. Here is how the two models compare, and how to pick.
Hosted checkout: the provider runs the page
With a hosted checkout, the buyer goes to a payment page the gateway runs, enters their card, and comes back once the payment is done. The card data never touches your servers.
That one fact drives everything. Because the sensitive data is captured on the provider's side, your PCI compliance scope shrinks dramatically. The provider carries the security hardening, the tokenization, and much of the fraud tooling. What you give up is control: you style the page within the provider's limits, but the flow and the redirect belong to the gateway.
For most businesses that is a good trade. The compliance and security savings are large, and the loss of control is small, especially now that hosted pages can be themed to match your brand closely.
Direct API: you run the page
With a direct API integration, the buyer stays on your pages, card details are captured there, and passed to the gateway through its API. No redirect. The experience is entirely yours.
The upside is total control: the checkout looks and behaves exactly as you designed, with nothing imposed by the provider. The cost is real. Capturing card data on your own pages pulls you into a much larger PCI scope, and the engineering and security work rises with it. This model suits businesses with the resources to carry that weight and a strong reason to own the whole experience, usually large merchants and platforms building their own checkout.
The middle ground most businesses want
The choice is not really binary anymore. Most gateways offer a drop-in or embedded-fields model that sits between the two. The payment fields are hosted by the provider but rendered inline on your page, usually in an iframe. The buyer never leaves your site, so it feels native. But because the sensitive fields are technically served by the provider, your compliance scope stays close to the hosted model.
For a lot of businesses, this is the sweet spot: a checkout that looks like yours, without the full PCI weight of a direct API build. You get most of the control of API-direct and most of the compliance relief of hosted, at once.
A common mistake is to reach for the full API build for control the business never actually uses. Teams picture a bespoke checkout, then ship something that looks almost identical to what an embedded model would have given them, having taken on the full PCI scope for the difference. Start from what you genuinely need to control, not from what is possible. For most businesses, the honest answer points to hosted or embedded.
The cost that shows up later
The decision is not only about launch effort. It is about who carries the maintenance.
Card standards change. Authentication rules shift by market. New payment methods appear constantly. With a hosted or embedded model, the provider absorbs most of that ongoing work, keeping the page compliant, rolling out new authentication, adding local methods. With a direct API build, much of that upkeep lands on your engineering team, and it does not stop. For a business selling across many markets, that open-ended burden often outweighs the one-time appeal of a fully custom checkout. It just does not show up on launch day.
How to choose
Three questions settle it. How much control do you genuinely need, not just want? How much PCI and security weight can you carry? And how much engineering time do you have to build and maintain a checkout?
Want to launch fast, keep compliance light, and accept a themed page? Hosted checkout. Need the checkout on your own pages but not the full custom build? Embedded or drop-in. Have a real reason to own the entire experience and the resources for full PCI scope? Direct API.
For cross-border businesses there is one more factor: coverage. Whichever model you pick, the gateway underneath has to support the local methods and currencies your buyers expect in each market, which is where a cross-border payment gateway earns its place. And whichever you pick, running 3DS authentication through it keeps fraud and chargebacks down without adding needless friction.
The right integration is the one whose trade-offs match your business, not the one with the most control on paper. For most, that is hosted or a hosted-backed embedded checkout: enough ownership of the experience, without inheriting the weight of running a card-capturing page yourself.
Sources
[1] PCI Security Standards Council. "PCI DSS and payment security standards." 2026.
