A hosted payment page (HPP) is a checkout page operated entirely on a payment provider's infrastructure. Instead of filling in card details on the merchant's own website, shoppers are redirected to — or presented with an embedded iframe from — a secure page controlled by a gateway or payment service provider. The merchant never sees or stores raw card numbers; only a token comes back. For most small and mid-sized merchants, this is the safest and fastest route to accepting card payments online.
How a Hosted Payment Page Works
Understanding the sequence of events clarifies exactly where security and responsibility sit.
Customer initiates checkout
Provider renders the payment form
Card data is captured and vaulted
Authorization request is sent
Result is returned to the merchant
Why Hosted Payment Page Matters
Choosing a hosted payment page is not just a technical decision — it carries significant business and regulatory weight for anyone selling online.
PCI scope reduction is the headline benefit. PCI DSS divides merchants into Self-Assessment Questionnaire tiers based on how they handle card data. Merchants using a fully redirected hosted payment page qualify for SAQ A — the simplest tier with roughly 22 controls — compared to SAQ D, which carries over 300 controls for merchants who process card data themselves. For a small team, the difference is weeks of compliance work vs. an afternoon.
Fraud and security costs shift to the provider. The 2023 Verizon Data Breach Investigations Report found that payment card data remains one of the most targeted asset types in web application attacks. When card data never touches merchant infrastructure, the attack surface shrinks to near zero from the merchant's perspective. The provider's security team, 24/7 monitoring, and dedicated PCI audits handle protection at scale.
Conversion impact is smaller than assumed. A 2024 Baymard Institute study found that 17% of US shoppers have abandoned a cart due to distrust of the payment page — meaning a well-branded, familiar hosted page from a recognised provider can actually increase trust vs. a homegrown form that looks unfamiliar. Latency is the real enemy: hosted pages loading over 3 seconds see a measurable drop in completion rates.
Regulatory note
Hosted Payment Page vs. Embedded Payment Form
Both approaches let customers pay on your site, but the technical and compliance implications are very different.
| Dimension | Hosted Payment Page | Embedded Payment Form |
|---|---|---|
| Card data path | Provider servers only | Merchant + provider servers |
| PCI SAQ tier | SAQ A (lightest) | SAQ A-EP or SAQ D |
| Customisation | Moderate (CSS, logo, colours) | Full (any UI possible) |
| Redirect required | Yes (or iframe) | No |
| Engineering effort | Low | Medium–High |
| Fraud liability | Largely on provider | Shared / merchant |
| Best for | SMBs, fast launches | Enterprise, bespoke UX |
For merchants prioritising launch speed and compliance simplicity, the hosted page wins. For those needing pixel-perfect UX control and willing to invest in security infrastructure, an embedded payment form may be justified.
Types of Hosted Payment Page
Not all hosted payment pages work the same way. Knowing the variants helps you choose the right integration.
Full-page redirect — The browser navigates away from the merchant's domain to the provider's URL. Simplest integration; requires one or two lines of server-side code. The customer sees a domain change in the address bar.
iFrame embed — The hosted page loads inside an <iframe> on the merchant's site, so the customer never appears to leave. The URL stays on the merchant's domain, but the card form is technically served from the provider. Qualifies for SAQ A if implemented correctly.
Custom subdomain (white-label) — The provider hosts the page but maps it to a merchant-controlled subdomain (e.g., pay.yourstore.com) using a CNAME. Offers the best of both worlds: full PCI offload with seamless brand continuity.
Payment link — A pre-built hosted page accessed via a shareable URL (email, SMS, WhatsApp). No ecommerce integration needed; the merchant sends the link and the customer pays. Common for invoicing and service businesses.
Best Practices
For Merchants
- Brand the page fully. Upload your logo, set brand colours, and if the provider supports it, use a custom subdomain. Unbranded hosted pages increase cart abandonment.
- Enable 3DS2. Activate Strong Customer Authentication even in markets where it is not yet mandatory — it shifts chargeback liability to the issuer for authenticated transactions.
- Test on mobile. Over 60% of ecommerce checkouts happen on mobile. Confirm the hosted page renders correctly on iOS Safari and Chrome Android before going live.
- Monitor provider uptime. Set up status-page alerts for your payment provider. An unmonitored outage can silently kill revenue for hours.
- Store the token, not the card. Use the payment token returned after the first transaction to power subscription billing and one-click repeat purchases without asking customers to re-enter details.
For Developers
- Validate the redirect URL server-side. Never trust the return URL sent by the browser — regenerate it server-side to prevent open-redirect attacks.
- Use webhooks, not redirect params, for order confirmation. Redirect parameters can be tampered with or missed if the user closes the tab. Treat the webhook as the authoritative source of truth.
- Implement idempotency keys. If a customer double-clicks or the webhook fires twice, idempotency prevents duplicate charges.
- Audit your iFrame Content Security Policy. If using an iframe embed, update your CSP
frame-srcdirective to allow only the provider's domain — nothing broader. - Log the full payment response. Store transaction IDs, gateway response codes, and timestamps. You will need them for dispute resolution and reconciliation.
Common Mistakes
1. Trusting redirect parameters for fulfilment. Redirecting back with ?status=success in the URL is not proof of payment. A determined user can manually craft that URL. Always confirm via webhook or a server-side status check before releasing goods.
2. Skipping mobile QA. Developers often test on desktop Chrome and miss layout issues on mobile browsers. Hosted pages with fixed-width forms or poor touch targets see significantly lower mobile conversion.
3. Not handling payment failures gracefully. Many integrations redirect declined customers to a generic error page. A better pattern is returning them to the cart with a specific, actionable message ("Your card was declined — try a different card or contact your bank") and preserving their cart state.
4. Assuming the hosted page covers all PCI requirements. SAQ A still requires merchants to maintain a secure website, use HTTPS, and have a policy for handling cardholder complaints. The hosted page reduces scope — it does not eliminate PCI obligations entirely.
5. Ignoring PCI compliance documentation. Some acquiring banks require merchants to submit their SAQ annually even when using a hosted page. Failing to do so can result in fines or account suspension, even though the technical risk is minimal.
Hosted Payment Page and Tagada
Tagada is a payment orchestration platform that lets merchants connect to multiple payment gateways — and their respective hosted payment pages — through a single integration. Rather than locking into one provider's hosted page, you configure routing rules so that transactions flow to the best-available gateway based on cost, acceptance rate, or geography.
Failover for hosted pages
This is especially valuable when operating across multiple markets: a European provider's hosted page may outperform a US-centric one for EUR transactions, while a local acquirer's page increases acceptance rates in Southeast Asia. Tagada normalises the integration so you get the compliance benefits of hosted pages everywhere, with the flexibility of a multi-gateway strategy.