Time for a Level Playing Field for Regulated UK Gambling Payments
Download Whitepaper
Payment Infrastructure

Hosted Payment Page

What Is a Hosted Payment Page? Definition and How It Works

Definition

A hosted payment page is a card data entry form served directly by a payment provider, where the cardholder enters payment details on the provider's infrastructure rather than the merchant's, reducing the merchant's PCI DSS scope.

How it works

When a merchant uses a hosted payment page, the checkout flow redirects the cardholder to a payment form hosted and served by the payment provider. Card data entered on this page goes directly to the provider's systems and never touches the merchant's servers or codebase. The provider handles card data collection, encryption, and tokenisation before passing a token or transaction reference back to the merchant.

This architecture means the merchant's environment is out of scope for card data under PCI DSS. Merchants using a hosted payment page where they do not receive, store, process, or transmit cardholder data can typically self-certify under SAQ A, the simplest PCI self-assessment type.

Hosted payment pages come in several implementation variants: a full-page redirect (the cardholder is sent to a separate URL), an embedded iframe (the form appears within the merchant's page design but is served by the provider), and a lightbox overlay. Each has different implications for UX continuity and PCI scope: iframes generally maintain SAQ A eligibility while keeping the visual checkout experience on the merchant's site.

The provider is responsible for the security, uptime, and PCI compliance of the hosted form itself. Merchants must still ensure they do not log or capture card data passed through URL parameters or form fields outside the hosted page.

Why it matters

PCI scope reduction is the primary commercial reason to use a hosted payment page: SAQ A qualification dramatically reduces annual compliance overhead compared to the SAQ D or QSA audit path required for direct API integrations where card data touches merchant systems.

Customization is limited compared to API integration: the merchant cannot fully control the checkout UX, form layout, or error handling behaviour when card entry is handled by the provider. This is an acceptable trade-off for many merchants but a blocker for those with strict brand or UX requirements.

Provider uptime becomes checkout uptime: since the hosted form is served by the provider, any downtime or performance degradation on the provider's infrastructure directly impacts the merchant's checkout conversion.

Mobile checkout requires careful implementation: hosted payment pages must be responsive and mobile-optimised. Providers vary significantly in the quality of their hosted form mobile experience, and this should be evaluated before selecting an integration approach.

With PXP

PXP's hosted payment page is available as a full-page redirect or embedded iframe. Both variants qualify merchants for SAQ A PCI scope. The page supports network tokenisation, multi-currency display, and 3DS 2.x natively without additional merchant-side configuration.

Talk to a payments specialist

Frequently asked questions

What's the difference between a hosted payment page and an iframe?

Both are hosted by the payment provider, but they differ in how they appear to the cardholder. A full-page redirect sends the cardholder to a separate URL on the provider's domain. An embedded iframe renders the payment form within the merchant's page, maintaining visual continuity while keeping card data off the merchant's servers. Both typically qualify for SAQ A.

Does using a hosted payment page completely eliminate PCI requirements?

No. SAQ A significantly reduces compliance scope but does not eliminate it. Merchants must still complete an annual SAQ A self-assessment and quarterly network scans, and are responsible for ensuring that no cardholder data is captured outside the hosted form, for example, via URL parameters, custom form fields, or browser-level logging.

How does a hosted payment page affect checkout conversion?

The impact depends on implementation quality. Full-page redirects can reduce conversion through friction and visual discontinuity. A well-implemented embedded iframe maintains checkout flow and reduces drop-off. Merchants should measure conversion rates by integration type and device category to quantify the difference for their specific audience.

Can hosted payment pages support recurring billing and stored credentials?

Yes, through tokenisation. When a cardholder pays via a hosted page, the provider returns a token representing the card. This token can be used for subsequent charges without requiring the cardholder to re-enter their details. The merchant stores the token, not the card data, and presents it for future authorisation requests through the API.