Hosted payment page: how it works, PCI scope, and trade-offs

A hosted payment page is a checkout page that your payment provider builds, runs, and secures. When a customer clicks Pay on your website, they're sent to the provider's page, type their card details there, and come back to your site once the payment is approved or declined. Your website never receives the card number. That one design choice is what keeps PCI compliance manageable for most small online sellers.

The catch is control. The page lives on someone else's server, so you get whatever logo, color, and text options the provider offers, and not much more. Below: how the handoff works, how a hosted page compares with embedded fields and a direct API integration, which PCI questionnaire each one usually lands you in, and what to do if you're worried about conversion.

How does a hosted payment page work?

The customer shops on your site and pays on the provider's. A typical sale runs like this:

1. The customer fills a cart and clicks Pay.
2. Your site sends the order amount and an order reference to the provider and redirects the customer.
3. The provider shows its payment page with your business name, the amount, and the card fields.
4. The customer enters the card. The provider runs your fraud rules and sends the authorization request.
5. The customer is sent back to a return page on your site with an approved or declined status.
6. Separately, the provider notifies your system, often with a server-to-server message called a webhook, so the order is marked paid.

Treat step 6 as the real confirmation. A customer can close the browser before the return page loads, and anyone who learns your return address can visit it without paying. Ship when the provider's notification, or your dashboard, says the payment was approved.

Payment links use the same kind of page. The only difference is how the customer arrives: from a text or email instead of your cart. We cover that side in our payment link explainer.

Hosted vs embedded vs direct API checkout: what's the difference?

The difference is who serves the card fields. With a hosted page, the provider serves the whole page. With embedded fields, the provider serves only the card fields, inside your page, usually in a frame. With a direct integration, your own page or server handles the card data and passes it to the provider.

Embedded fields are the middle path, and for some stores they're the right one. But they come with an extra PCI step that a plain redirect doesn't, which the next section explains. If the gateway's role in each setup is fuzzy, start with what a payment gateway is.

Which PCI questionnaire does a hosted payment page qualify for?

Usually SAQ A, the shortest self-assessment questionnaire. It's written for card-not-present merchants that fully outsource card handling to PCI DSS validated providers and don't store, process, or transmit card data electronically themselves (PCI SSC). A hosted page is the cleanest way to meet that description.

Three details changed recently, and they're worth knowing before you choose a checkout.

First, the 2025 SAQ A revision. As of March 31, 2025, PCI SSC removed two payment-page script requirements, 6.4.3 and 11.6.1, from SAQ A and added an eligibility criterion instead: you must confirm your site isn't susceptible to attacks from scripts that could affect your e-commerce systems (PCI SSC). A follow-up FAQ says the criterion applies to sites that embed a payment form, not to plain redirects, and that you can meet it with your own script protections or with your provider's confirmation that its embedded form includes them (PCI SSC FAQ 1588). This is the main PCI advantage a redirect still has over an iframe.

Second, scans. For PCI DSS v4.x, PCI SSC added external vulnerability scans by an Approved Scanning Vendor (ASV) to SAQ A. They cover the system that hosts the page that redirects customers to the provider or embeds its form (PCI SSC). Ask your acquirer how often it wants scan reports. Hosted doesn't mean nothing to do; it means much less.

Third, the scripts behind the change. PCI SSC published an information supplement on payment page security and preventing e-skimming, written as guidance for Requirements 6.4.3 and 11.6.1 (PCI SSC). If you ever move off a hosted page to a form you build yourself, expect that guidance to become your reading.

When you move past SAQ A

Build your own payment form, even one that posts card data straight to the gateway, and you're likely in SAQ A-EP. It covers e-commerce merchants whose website doesn't receive card data but can still affect the security of the payment (PCI SSC). If card data passes through your servers, you're in SAQ D, the catch-all for merchants the shorter questionnaires don't describe (PCI SSC).

Here's how that plays out. Say a skate shop in Boston redesigns its site, and the developer suggests replacing the hosted page with a custom card form "so it matches the theme." That one change can move the shop from SAQ A to SAQ A-EP, with a much longer questionnaire and more security work every year. Nobody set out to make compliance harder; it happened as a side effect of a design choice. Your acquirer decides which questionnaire you file, so ask before the redesign ships, not after. Our guide to what PCI compliance is covers every questionnaire in plain English.

Do hosted payment pages lower conversion?

They can, when the handoff feels abrupt. A hosted page that looks like your store, uses your business name, and asks only for what it needs usually doesn't cost you much. There's no trustworthy universal number for the drop-off, so your own checkout data is the figure that matters.

What makes customers hesitate at a redirect:

• The page looks nothing like your store.
• The business name on the page doesn't match your store name.
• There's no order summary, so the customer isn't sure what they're paying for.
• The form asks for fields it doesn't need.
• On a phone, the page loads slowly or zooms oddly.

Most of those are fixable inside a hosted page's settings. Upload your logo, set your colors, show the order total and a short description, and test the whole flow on your own phone over a cellular connection. Then measure it. Compare the number of customers who clicked Pay with the number who paid, every week. A bookstore in Pittsburgh selling signed editions online can track that gap in a spreadsheet. If it's large and the redirect is the cause, embedded fields are the next step, not a custom form.

Our honest view: for most small stores, the conversion you might gain from a fully custom checkout is smaller than the compliance work it adds. Big stores with developers and real checkout data can reach a different answer, and that's fine.

When is a hosted payment page the wrong choice?

A hosted page is the right default for most small businesses, but not for all of them:

• You run a high-volume store where checkout design is a measured revenue lever, and you have developers to maintain it. Embedded fields usually make more sense.
• You sell inside a mobile app. Apps generally use the provider's in-app payment tools rather than a web redirect.
• Your shopping cart platform decides which payment options you can use. Work within its list, and pick the option that keeps card data off your systems.
• Most of your orders come by phone. A virtual terminal fits better, with SAQ C-VT as the likely questionnaire.

If none of those describe you, start hosted and revisit it once you have a few months of checkout data.

How do you set up a hosted payment page?

Setup is mostly settings, not code, but the order matters. Work through it like this:

1. Check that your website builder or shopping cart supports your provider's hosted checkout, or ask the provider how to connect it.
2. Add your logo and colors, and use the business name that appears on your store and on customers' card statements.
3. Set the return pages for approved and declined payments, each with a clear next step for the customer.
4. Connect payment notifications to your order system, and test that an order is marked paid only when the notification arrives.
5. Turn on address verification, security code checks, and velocity limits, and decide when you'll use 3-D Secure.
6. Run live payments with your own card on a laptop and a phone, include one deliberate decline, then refund them.
7. Book the ASV scan for your website and confirm with your acquirer that you'll file SAQ A.
8. Write down who owns the checkout setup, so a future redesign doesn't quietly replace it.

On step 5, 3-D Secure is worth a look if you sell items that are easy to resell. Under Visa Secure, a successfully authenticated sale protects you from fraud-related disputes (Visa). Whether the extra checkout step pays for itself is a numbers question, and ecommerce fraud prevention walks through the math.

What should you ask a provider about its hosted checkout?

1. What can I customize: logo, colors, button text, which fields appear?
2. Can the page show my order summary and the business name customers know?
3. How does it look and perform on a phone?
4. Which fraud checks run on it: address verification, security code checks, velocity limits, 3-D Secure?
5. How will my system learn that a payment was approved?
6. Can it save cards as tokens for repeat customers and subscriptions, and can I export them if I leave?
7. Will you give me a copy of your PCI Attestation of Compliance?
8. If I move to embedded fields later, will you confirm in writing that they include the script protections PCI SSC's FAQ describes?
9. What does it cost each month and per transaction?

Clearo's online payments include hosted checkout and gateway integration, with fraud screening through AVS, CVV checks, and velocity rules. If you want the bigger picture of channels beyond the website, see how to accept payments online.

Common hosted payment page mistakes

• Assuming hosted means no PCI work. You still complete SAQ A every year and keep up with scans.
• Swapping the hosted page for a custom form during a redesign without checking what it does to your questionnaire.
• Shipping orders when the return page loads instead of when the provider confirms the payment.
• Letting the business name on the hosted page drift from the name on your store and card statements.
• Taking a card number by email when a customer can't get through checkout. Send a payment link instead.
• Never testing the page on a phone, where most customers will see it first.

PCI DSS is one standard across every state, so this advice holds whether your store ships from New England or anywhere else in the United States.

Your next step

If you're running a custom checkout and aren't sure which questionnaire it puts you in, or your statement shows gateway fees you can't explain, send it to us for a free statement review. We'll tell you what each line is for. If you're setting up online payments from scratch, contact us about hosted checkout on interchange-plus pricing.