---
title: "Hosted Payment Page"
url: "https://mahouse.world/glossary/hosted-payment-page"
type: "glossary term"
topic: "Checkout"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-10"
---

# Hosted Payment Page

A hosted payment page is a checkout page — or, in its modern form, embedded fields or an iframe within the merchant's page — served by the payment provider rather than the merchant, so the card number is entered into the provider's domain and never touches the merchant's systems. It takes the merchant almost entirely out of PCI DSS scope, once at the cost of a redirect, which hosted fields removed.

**Also known as:** Hosted checkout, Redirect checkout, Hosted fields, Payment iframe

## Key facts

- **Used at:** most small and mid-sized e-commerce checkouts; enterprise checkouts through embedded fields; any merchant that wants card acceptance without the PCI burden of handling card data
- **Binding:** PCI DSS scoping rules — a merchant using a fully hosted page or validated hosted fields qualifies for SAQ A (a few dozen questions); one whose own page captures the card and posts it to the PSP does not; version 4.0 adds requirements on scripts and integrity for payment pages
- **Typical forms:** full redirect (the shopper leaves the merchant's site for the PSP's page and returns), hosted fields (the PSP's inputs embedded in the merchant's form, styled to match, each an iframe), and drop-in components (the PSP's whole payment element, with methods and 3DS, embedded)
- **Typical trade-offs:** full redirects cost conversion (a foreign page, a broken back button) and are now rare at scale; hosted fields keep the merchant's design and the PSP's scope reduction; the merchant loses some control over the exact experience and gains a page it does not have to secure
- **Parties:** the merchant, the PSP that hosts the page or fields, the shopper, the PCI assessor who reads the scoping, and the fraudsters whose skimming scripts the hosting is meant to keep out

## How a hosted payment page works in practice

A shopper on a merchant's checkout enters a card number into what looks like the merchant's form. The field is an iframe served from the PSP's domain: the keystrokes go to the PSP, which tokenises the card and hands the merchant a token to submit the payment with. The merchant's servers never see a card number; its page cannot read the iframe's contents; a skimming script injected into the merchant's site cannot capture what the merchant's page cannot see (which is the point, and also the residual risk that version 4.0's script-integrity rules address). The merchant's PCI questionnaire is SAQ A: it has outsourced card capture to a validated provider and must confirm that its page does not touch the data.

The history is the redirect. Early hosted pages sent the shopper to the PSP's site — a different look, a URL the shopper did not recognise, a confirmation that returned late — and merchants lost sales to the confusion. Hosted fields solved it: the PSP's inputs, the merchant's design; drop-in components went further, embedding methods, wallets and 3-D Secure in one element. The redirect survives for some alternative payment methods (the shopper must go to their bank or wallet) and for merchants that want no checkout engineering at all.

For a merchant, the choice is between the PSP's page and its own PCI programme; for a payments company, the hosted components are the product surface that decides which merchants integrate.

## Example

A mid-sized retailer captures card numbers on its own checkout page and posts them to its PSP's API. It validates on SAQ A-EP — about 190 questions — with an annual cost of €60,000 in consultancy and quarterly scans, and a security review after every checkout change. A skimming script through a compromised analytics tag harvests 12,000 cards over six weeks. The rebuild uses the PSP's hosted fields: the same visual design, the card inputs in iframes, the token returned to the merchant. PCI scope falls to SAQ A (€8,000 a year); the breach vector is closed because the page can no longer see the card; conversion is unchanged, because nothing the shopper sees changed. The retailer's payments lead notes that the €52,000 a year saved is smaller than the breach's €700,000 cost, and that both were avoidable in 2019.

## Common mistakes

- A redirect checkout in 2025, losing sales the embedded form would keep.
- Capturing the card on the merchant's page "for the design" and inheriting the full PCI scope.
- Hosted fields with a script on the merchant's page that reads the iframe's parent form — bringing the data back into scope.
- Assuming SAQ A means no obligations; the merchant's page and its scripts are still controls.
- Choosing a PSP for its hosted checkout and never testing it on a phone.

## Related terms

- [Payment Gateway](https://mahouse.world/glossary/payment-gateway.md)
- [PCI Compliance Level](https://mahouse.world/glossary/pci-compliance-level.md)
- [PCI DSS](https://mahouse.world/glossary/pci-dss.md)
- [Cart Abandonment](https://mahouse.world/glossary/cart-abandonment.md)
- [Tokenization](https://mahouse.world/glossary/tokenization.md)
- [Guest Checkout](https://mahouse.world/glossary/guest-checkout.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov