Hosted Payment Page

What Is a Hosted Payment Page?

A hosted payment page (HPP) is a checkout form that a payment gateway or payment service provider hosts on its own domain. When a customer is ready to pay, the merchant's website redirects them to the provider's page (or opens it as an overlay), where they enter their card number, expiration date, and CVV. After the transaction is authorized, the customer is redirected back to the merchant's site with a confirmation.

The core value proposition is security through separation. Because the card details are entered on the provider's domain and processed by the provider's infrastructure, the merchant's systems never see raw cardholder data. This dramatically reduces the merchant's PCI DSS compliance scope: a process that might otherwise require hundreds of security controls and a formal audit.

Hosted payment pages are one of the oldest and most widely used integration patterns for online payments. Providers like Stripe (Checkout), Adyen, Checkout.com, and PayPal all offer some form of hosted page, though newer embedded approaches are increasingly common for merchants who want more control over the checkout experience.

How It Works

The hosted payment page flow involves a handoff between the merchant's site and the provider's infrastructure. At no point does the merchant's server handle card data directly.

1. The customer adds items to their cart and clicks "Pay" on the merchant's site
2. The merchant's server creates a payment session with the provider via API, passing the order amount, currency, and a return URL
3. The provider returns a unique URL for the hosted payment page
4. The customer is redirected to that URL (or it opens in a modal overlay)
5. The customer enters card details on the provider's domain and submits the form
6. The provider processes the authorization, applies fraud checks and 3D Secure if required
7. The customer is redirected back to the merchant's site with a transaction result
8. The provider sends a webhook to the merchant's server confirming the payment status

Redirect vs. Overlay Implementations

Hosted payment pages come in two primary forms, each with distinct UX characteristics:

• Full-page redirect: the customer leaves the merchant's site entirely and lands on the provider's domain. The URL bar changes, which can erode trust if the provider's branding is unfamiliar, but also signals to security-conscious users that a specialized payment handler is processing their data
• Overlay (lightbox or modal): the payment form appears as a popup layer over the merchant's page. The merchant's site remains visible in the background. This feels more seamless but the form content still loads from the provider's domain inside an iframe

Overlays generally produce better conversion rates because they avoid the jarring context switch of a full redirect. However, redirects are sometimes unavoidable: European bank-redirect methods like iDEAL or Bancontact require a true redirect to the bank's authentication page, and mobile browsers can handle redirect flows more consistently than overlay iframes.

PCI DSS Scope and Integration Models

The primary reason merchants choose hosted payment pages is to minimize their PCI DSS compliance obligations. PCI DSS defines several Self-Assessment Questionnaire (SAQ) types based on how a merchant handles card data. The integration model determines which SAQ applies:

SAQ A is the lightest compliance path available: roughly 27 questions in PCI DSS v4.0, focused on verifying that the merchant has outsourced all card handling. SAQ A-EP is significantly heavier because the merchant's website serves the page that contains the payment iframe, so any compromise of the merchant's site (like a cross-site scripting attack) could potentially intercept card data. SAQ D is the full assessment and is required when the merchant's systems directly process, store, or transmit card data.

It is worth noting that a hosted payment page does not automatically make a merchant PCI DSS compliant. The merchant must still validate that every payment channel meets the SAQ A criteria. If the same merchant also takes phone orders by typing card numbers into a CRM, that channel would push the entire business to a higher SAQ level.

Customization Options

Modern hosted payment pages offer branding controls so the checkout experience does not feel like a completely separate website:

• Logo upload (typically limited to around 200 x 80 pixels)
• Brand color applied to the page background and primary buttons
• Custom fonts and favicon for browser tab recognition
• Footer links to the merchant's terms of service and privacy policy
• Language and locale selection for international customers
• Option to remove the provider's own branding from the page

The level of customization varies significantly by provider. Some handle changes through an account manager, while others offer self-service dashboards. Even with full branding applied, the URL bar still shows the provider's domain on redirect-based implementations, which limits true white-label presentation.

Use Cases

Small and Mid-Size E-Commerce

Merchants without dedicated security teams benefit most from hosted payment pages. The integration is straightforward: generate a session via API, redirect the customer, handle the webhook. There is no need to build a payment form, manage tokenization infrastructure, or undergo a heavy compliance audit. For a business processing fewer than six million card-not-present transactions annually (PCI Level 2, 3, or 4), SAQ A self-assessment is the fastest path to accepting payments online.

Marketplace and Platform Payments

Platforms that onboard third-party sellers (marketplaces, SaaS platforms with billing) often use hosted pages to keep their sellers' payment flows standardized and compliant. The platform never touches card data for any seller, which simplifies the compliance story across potentially thousands of sub-merchants.

Recurring Billing and Subscriptions

Many providers combine hosted payment pages with card-on-file tokenization. The customer enters their card once on the hosted page, the provider stores a token, and subsequent charges use that token without requiring the customer to re-enter details. This pattern gives the merchant the compliance benefits of a hosted page for the initial capture while enabling automated recurring billing afterward.

Multi-Currency and Cross-Border

Hosted pages from global providers often support dynamic currency conversion and local payment methods out of the box. A single integration can present credit cards, bank redirects, digital wallets, and buy-now-pay-later options based on the customer's location, without the merchant needing to build separate flows for each method.

Crypto Payment Pages

Cryptocurrency checkout pages follow a fundamentally different model from traditional hosted payment pages. Instead of collecting card numbers and CVVs, a crypto payment page displays a wallet address and a QR code that the customer scans with their wallet app.

A typical crypto checkout flow works as follows:

1. The customer selects a cryptocurrency or stablecoin at checkout
2. The payment page displays the recipient address, a QR code encoding that address (and optionally the amount and network), and an expiration timer (commonly 15 minutes)
3. The customer sends the exact amount from their wallet
4. The provider monitors the blockchain for the incoming transaction
5. After on-chain confirmation, the customer is redirected to a success page

Because no card data is involved, PCI DSS compliance is irrelevant for crypto-only payment pages. The security concerns shift to address verification (ensuring the customer sends to the correct address on the correct network), underpayment handling, and price volatility during the confirmation window. Providers typically lock in an exchange rate for the duration of the payment timer.

For merchants accepting both card and crypto payments, hosted pages from providers like Spark and others can present both options on a single checkout flow, letting the customer choose their preferred rail. The emergence of stablecoin payment pages has also simplified the crypto checkout experience by removing the volatility concern entirely: a $50 payment in USDC stays $50 regardless of confirmation time. For more on how stablecoins are reshaping online checkout, see the research on embedded stablecoin checkout integration.

Conversion Trade-Offs

The main drawback of hosted payment pages is their impact on checkout conversion. Every redirect is a potential drop-off point. Processor data from Adyen suggests that merchants who migrated from hosted pages to embedded checkout components saw conversion improvements between 3.6% and 15%, though these figures come from the provider's own migration campaigns rather than independent studies.

Several factors contribute to this conversion gap:

• The redirect breaks the customer's mental flow: leaving the merchant's site introduces doubt and creates an opportunity to abandon
• Page load time for the hosted page adds latency that compounds on slow connections
• The unfamiliar domain in the URL bar can trigger suspicion, particularly for smaller or less-known payment providers
• Mobile browsers handle redirects inconsistently, and some customers lose their session or cart state during the round-trip

That said, a well-branded hosted page from a recognized provider can outperform a poorly implemented embedded form. Execution quality matters more than integration pattern. For merchants evaluating the trade-off, the research on checkout conversion and crypto friction explores how different payment integration approaches affect completion rates.

Risks and Considerations

Provider Dependency

With a hosted payment page, the provider's uptime is the merchant's checkout uptime. If the provider experiences an outage, the merchant cannot process any payments. This is a critical dependency that merchants should evaluate alongside the provider's SLA and historical reliability. Some payment orchestration platforms mitigate this by routing to a fallback provider when the primary is unavailable.

Limited UX Control

Even with customization options, hosted pages cannot match the design flexibility of a fully native checkout. Merchants cannot implement custom form validation, inline address lookup, or tightly integrated loyalty program flows on a page they do not control. For high-volume merchants where checkout conversion directly affects revenue, this limitation often drives migration to embedded solutions despite the increased PCI burden.

Security of the Redirect

While hosted pages remove card data from the merchant's scope, the redirect itself can be a target. Phishing attacks may attempt to redirect customers to a lookalike payment page. Merchants should use HTTPS exclusively, validate redirect URLs server-side, and consider implementing Content Security Policy headers to prevent unauthorized redirects. The provider's hosted page URL should be predictable and verifiable by the customer.

Fraud and Chargeback Handling

A hosted payment page handles card data collection but does not eliminate payment fraud. The merchant is still liable for chargebacks on fraudulent transactions. Most providers include basic fraud scoring and 3D Secure support, but merchants processing high-risk or high-volume transactions may need additional fraud prevention layers beyond what the hosted page provides.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.