Payment Page
Dedicated webpage where customers enter payment information. Can be hosted (PSP-hosted) or embedded (merchant-hosted iframe).
Overview
What is Payment Page?
A payment page is the actual screen where a customer enters card details to complete a purchase, and it comes in two structurally different forms: hosted, where checkout redirects to a page controlled by the PSP on a different domain, and embedded, where the PSP's form loads inside an iframe on the merchant's own checkout page so it looks native to the site.
The difference isn't cosmetic — it changes who ever touches raw card data. On a hosted page, card details go straight to the PSP and never pass through merchant infrastructure at all. On an embedded iframe, the data still routes directly to the PSP, but the merchant's page hosts the collection surface, pulling more PCI scope onto the merchant even though the experience feels more seamless and on-brand.
That scope difference carries a real cost: a hosted page typically qualifies for the short SAQ-A questionnaire (14 questions, roughly $500-2K in annual compliance), an embedded iframe requires SAQ A-EP (182 questions, $3K-8K), and a fully direct integration needs the full SAQ-D (329 questions, $8K-20K) — a gap of several thousand dollars a year for most merchants, before counting that hosted pages carry no card-data breach liability at all since the data never reaches merchant servers.
The tradeoff runs the other way on conversion: a redirect to an unfamiliar domain reads as suspicious to some customers and typically costs 2-5% in checkout abandonment — exactly what a well-branded hosted page (merchant logo, matching colors, a line explaining the redirect beforehand) is meant to close. Most merchants come out ahead on hosted pages once properly branded; embedded iframes are worth the extra compliance scope specifically when redirect friction is costing more in lost conversion than the added PCI burden costs in compliance overhead.
In depth
Everything you need to know.
Hosted: Customer clicks checkout. Merchant redirects to PSP's payment page (different domain). Customer enters card details on PSP page. PSP processes payment. Redirects customer back to merchant with success/failure. Card data never reaches merchant servers. Embedded: Merchant embeds PSP iframe in checkout page. Customer enters card details in iframe (looks like merchant site). Iframe securely transmits to PSP. PSP processes, returns result. Appears seamless but iframe handles card data, not merchant servers.
Payment page choice affects PCI compliance costs dramatically. Hosted pages qualify for SAQ-A (14 questions, $500-2K annual compliance). Embedded iframes require SAQ A-EP (182 questions, $3K-8K). Direct integration (no hosted/iframe) requires SAQ-D (329 questions, $8K-20K). For $500K-5M annual merchants, this $2.5K-18K annual difference matters. Hosted pages also eliminate data breach liability - card data never on merchant servers means breach can't expose card numbers. However, hosted redirects reduce conversion 2-5% from checkout friction (leaving site, different branding). Must balance compliance savings vs. conversion impact.
Illustrative example — not a specific client engagement.
- Supplement merchant used direct card integration. SAQ-D compliance: $12K annually. Switched to hosted payment pages. SAQ-A: $2K annually. Saved $10K annually with actually better security.
- E-commerce merchant poorly branded hosted page (generic white PSP page). Customers saw domain change, thought phishing. 8% abandoned at payment page. Re-branded with logo, colors, trust messaging. Abandonment dropped to 3%.
- Subscription service used hosted redirect. 4% conversion loss from redirect friction. Switched to embedded iframe. Conversion recovered. PCI compliance costs increased from $2K to $6K annually but conversion gain ($120K additional revenue) justified easily.
- For most merchants: use hosted payment pages - minimize PCI scope, reduce compliance costs $10K-15K annually
- Brand hosted pages: add logo, match colors, clear messaging - maintain trust through redirect
- Explain redirect before it happens: 'You'll be redirected to secure payment page' reduces abandonment
- Test all redirect scenarios: successful payment, declined, timeout, customer back-button
- For high conversion requirements: use embedded iframe - seamless experience with reasonable PCI scope
- Ensure mobile-optimized - 50-70% of traffic mobile, desktop-only pages lose half your customers
- Only use direct integration if absolutely necessary - PCI burden and liability rarely justified
- Using direct integration when hosted would work - paying $15K-45K extra annually in PCI compliance
- Poorly branded hosted pages - customers see generic PSP page, don't trust, abandon (5-10% conversion loss)
- Not testing redirect flows - broken returns from hosted page leave customers confused
- Assuming embedded iframe is same PCI scope as hosted - iframe requires more complex compliance
- Not explaining redirect - customers surprised by domain change, think it's phishing
- Mobile-unfriendly hosted pages - 30-50% of traffic on mobile, desktop-only pages kill conversion
Keep exploring
Related terms
Put this to work
for your business.
MIDs structures high-risk acquiring across 30+ banks — smart routing, fraud and chargeback control built in. Tell us your category and volume and we'll build the setup around it.