Hosted checkout
A prebuilt payment page hosted by the processor, reducing your PCI burden.
Hosted checkout redirects customers to a payment page hosted and secured by the processor, so card data never touches your servers. It's quick to implement and shrinks your PCI scope, at the cost of some control over the checkout experience.
How it works
The reason to use one is SAQ A. Card data never reaches your servers, so your PCI DSS obligation usually collapses to that questionnaire, the shortest of them, rather than the far longer versions that apply when card fields sit on your own pages. It saves audit time and removes a category of breach risk. What you give up is control: the provider's layout, the fields it supports, whatever address or upsell logic it has chosen to offer. Larger merchants tend to move to an embedded form later for exactly that reason.
The flow itself is short. Your server tells the processor what is being bought, the line items, the amount, the currency, and the URLs to return to, and gets back a session identifier. The customer lands on a page served from the processor's domain, or an overlay drawn from it, and types the card number into fields your code cannot read. The processor authorizes, sends the customer to your success URL, and separately posts a webhook to your server confirming what happened.
Trust the webhook, not the redirect. Someone who pays and then closes the tab never reaches your success page, so an order marked paid only on return will simply go missing. Two more questions before you commit. Can the page run on your own domain, and does the provider charge for that? And can saved-card tokens be exported if you leave? A hosted checkout is the hardest part of a stack to migrate, which makes the second answer matter more than it looks on day one.
Worked example
A $95 order, paid on the provider's page. Your server opens a checkout session, the browser hands the customer over, the card is authorized, and they come back to your thank-you page while a webhook marks the order paid. At 2.9% + $0.30 the fee is $3.06 and you keep $91.94. No card number ever touched your server, so the annual PCI paperwork stays SAQ A.
Frequently asked questions
- Does a hosted checkout make me PCI compliant?
- Not automatically, though it does change what compliance means for you. Card data never reaching your systems is what qualifies most merchants for SAQ A, the shortest self-assessment, instead of a questionnaire covering your own servers and network. You still complete and submit it yourself. You still keep skimming scripts off the pages that lead to the redirect, and you still answer honestly about any other card handling, phone orders included.
- What is the difference between hosted checkout and an embedded payment form?
- Where the card fields live. A hosted checkout sends the shopper to a page on the provider's domain. An embedded form keeps them on yours and loads the input fields from the provider inside an iframe. Both keep card data out of your servers and both usually qualify for a reduced PCI scope, so the choice comes down to layout control, where the embedded version wins comfortably.
- Does redirecting to a hosted checkout lose sales?
- A small amount of conversion, yes, mostly on mobile and mostly when the page looks nothing like the site the shopper just left. The fixes are dull and they work: use the provider's branding options so the logo and colours match, keep the wallet buttons (Apple Pay, Google Pay) at the top, and check that the back button lands on a cart that still holds the items.