The three shapes, and what actually separates them
Every card integration is one of three things. Providers give them different names, but the distinction that matters is where the card details go and who is therefore responsible for them.
| Shape | Where the customer is | Where card data goes | Your compliance burden |
|---|---|---|---|
| Hosted checkout | On the provider's page or a redirect | Never touches you | Smallest |
| Embedded fields | On your page, in an iframe the provider serves | Browser straight to the provider | Small, and the usual answer |
| Full API | Entirely your interface | Through your servers | Large, and rarely worth it |
The middle row is the one most people want and the one most often missed, because from a distance it looks like the third. The customer never leaves your page and the design is yours, but the fields where the card number is typed belong to the provider and the data never reaches your code.
What each one costs you
| Hosted checkout | Embedded fields | Full API | |
|---|---|---|---|
| Time to first working payment | Hours | Days | Weeks, then more weeks |
| Design control | Almost none | Nearly complete | Complete |
| Handles authentication steps for you | Yes | Yes, through the provider's component | You build the flow |
| Handles new payment methods for you | Yes, usually automatically | Usually | You build each one |
| Card data compliance scope | Minimal | Minimal | Substantial and audited |
| Mobile and wallet support | Provider's problem | Provider's problem | Yours |
| Breaks when the provider changes something | Rarely, they manage it | Occasionally | Frequently |
The row that decides it for most businesses is the last one. A hosted or embedded integration is maintained by somebody whose job it is. A full API integration is a thing you now own, including every future authentication requirement and payment method your customers start expecting.
The conversion argument, and how much of it is real
The usual case for building your own flow is that a redirect loses sales. Sending somebody to a differently branded page mid-purchase does cost something, and on mobile the round trip is worse. That part is not imaginary.
The part that usually is imaginary is the assumption that a full API integration is required to fix it. Embedded fields already keep the customer on your page under your design. Choosing the third option to solve a problem the second one solves is how teams end up owning card data for no gain.
There is also a conversion argument in the other direction that gets left out. Hosted checkouts are maintained by companies that test them continuously and support wallets, saved cards and one-tap payment out of the box. A hand-built form frequently converts worse than the hosted page it replaced, because those features are missing and nobody counted them.
When building it yourself is genuinely right
It is a real answer in a small number of cases, and they have a common shape: the payment is not a checkout.
- You are a marketplace splitting one payment between several recipients, which changes the money flow rather than the form.
- The payment happens inside another process entirely, such as a device, a kiosk, or an agent completing something on a customer's behalf.
- You need payment methods your provider's hosted surface does not cover in your market.
- You are large enough that a fraction of a percent of processing cost pays for a team, and you have that team.
Note that none of these are about design. Wanting the checkout to look right is not a reason to take on card data, because the second option already gives you that.
The question that decides it faster than comparing fees
Ask who will fix this in eighteen months when an authentication rule changes, a card network adds a requirement, or customers start expecting a payment method that did not exist when you built it. If the answer is a person you have, the third option is available to you. If the answer is nobody in particular, it is not, whatever the fee comparison says.
Fees are the thing people compare first because they are the only number on the page, and they are usually the least significant difference between two viable choices at small volume. The maintenance question separates them permanently, and it separates them before you have written anything.
How hard is it to leave
The choice above also decides how expensive it is to change your mind. A hosted or embedded integration is a small surface, so replacing the provider is mostly replacing that surface. A full API integration spreads provider-specific assumptions through your order handling, your retry logic and your reconciliation, and moving means touching all of it.
One thing is awkward whichever shape you chose, and it is worth knowing before you need it. Saved cards belong to the provider that tokenised them, so your customers' stored payment methods do not simply come with you. Providers can often arrange a migration between themselves, but it is a request with conditions rather than an export you can run, and it is not something to discover during a switch you are already committed to.
Ask about this at the start rather than at the end. The answer costs nothing to obtain while you are still a prospect.
What this does not cover
- This compares integration models, not providers. It was planned as a comparison of gateways available in India and that version was not written, because we have not run those gateways in production and a ranking we cannot back is worth less than nothing.
- It contains no fees, settlement periods or rates for anyone. Those change and vary by account.
- The conversion points are the mechanics of why each shape helps or hurts, not measurements. We have not run a conversion test on any of them and would not publish a percentage we had not measured.
- It covers card payments. UPI, wallets, bank transfer and direct debit have their own flows and several statements here do not carry across.
- PCI scope depends on precisely how an implementation handles card data, and using an embedded field incorrectly can put you back in scope. Confirm your own position with your provider rather than assuming it from the table.
- Nothing here is legal or compliance advice.
Sources
- PCI Data Security Standard, which sets the scope difference between these shapes, PCI Security Standards Council. Retrieved 31 August 2026.
- Payments documentation covering hosted, embedded and API integrations, Stripe. Retrieved 31 August 2026.
- Payments documentation for the Indian market, covering the same three shapes, Razorpay. Retrieved 31 August 2026.
- EMV 3-D Secure, the authentication step hosted surfaces handle for you, EMVCo. Retrieved 31 August 2026.
Revisions
- 31 August 2026 First published.
This page is revised in place rather than replaced, so its address does not change.