What is hosted checkout, and how is it different from embedded?
The integration choice you make in week one decides how much of a payments company you have accidentally become.
The boundary line is what you are actually choosing.
What you are actually trading
Compliance scope. This is the real decision. If card details never touch your systems, your PCI DSS obligations are dramatically smaller: typically the shortest self-assessment questionnaire rather than an audited programme. Hosted keeps you furthest from the data. Embedded, done properly with provider-supplied fields, also keeps card data out of your systems but places more of the page under your control and therefore more of the integrity of that page under your responsibility.
Conversion. A redirect costs you customers. The page looks different, the URL changes, mobile behaviour gets awkward, and some people abandon at exactly that moment. Embedded keeps the customer in one context. The size of the effect varies enormously by market and audience, and it is genuinely measurable, so measure it rather than accepting anyone's published figure.
Control. Hosted pages are configurable within limits. If you need an unusual flow, a custom payment-method order, or a checkout that matches your product precisely, hosted will eventually block you.
Maintenance. Hosted means the provider handles new payment methods, new authentication requirements and browser changes. Embedded means you carry more of that, forever. Authentication requirements in particular have a history of changing under merchants, and a hosted page absorbs it while an embedded one becomes your sprint.
The trap people fall into
Building your own card form and posting it to an API.
It looks like the simplest option and it is by far the most expensive, because the moment card data touches your server you have pulled your entire infrastructure into audit scope. That is not a form of validation, it is an annual programme with real cost and real consequences when something goes wrong.
Almost nobody needs this. If you find yourself reaching for it because the provider's fields will not style the way you want, the honest comparison is a styling constraint against a compliance regime, and the styling constraint should win.
How to actually choose
Start hosted if payments are not your product. It is faster, cheaper to maintain, and reversible.
Go embedded when checkout friction is measurably costing you more than the maintenance burden, and when you have someone who will own it after launch. Not before.
And separate the question from your provider choice. Most serious providers offer both, and moving from hosted to embedded later with the same provider is a far smaller project than switching providers, which means this decision is much less permanent than it feels in week one.
A shop with its own till, against one that sends you next door to the post office counter to pay. The second is less work for the shopkeeper and the money is just as safe. Some customers walk out of the door and keep walking.
Where you meet it
Every checkout that suddenly changes to a different-looking page. Every card form that looks like part of the site but is quietly the provider's. Every small merchant whose payment page is on a domain you have never heard of.
Building this? A second pair of eyes on the architecture is what the advisory is for. →
