Hosted checkout reduces PCI scope; it does not erase the merchant boundary

“We use hosted checkout, so PCI does not apply to us” is too broad. Outsourcing card-data collection can reduce the merchant environment’s exposure and validation work. The correct boundary still depends on the integration, every eligibility criterion, the acquiring relationship, and systems that can affect the payment journey.

This guide is an architecture worksheet, not a compliance determination. Confirm the applicable PCI DSS validation method with the acquirer or other compliance-accepting entity.

Draw the browser path

Start with what the customer’s browser receives, not the product name. In a full redirect, the merchant page directs the browser to a provider-controlled payment page. In an embedded design, a provider form may appear inside an iframe while the surrounding page comes from the merchant. In a merchant-built form, merchant code handles payment fields or data before sending it onward.

PCI SSC says SAQ A eligibility requires all payment-page elements to originate from compliant service providers and all other criteria to be met. Its iframe FAQ distinguishes elements involved in collecting or processing card data from unrelated surrounding content (PCI SSC payment-page FAQ). A processor’s “hosted” label does not answer where every element originates.

Separate data scope from influence

Inventory systems that store, process, or transmit account data. Then inventory systems that can influence the payment path: DNS, content delivery, tag manager, JavaScript dependencies, deployment pipeline, administrator accounts, redirect configuration, and the application that creates checkout sessions. The second list matters even when raw card numbers never touch the merchant server.

PCI SSC’s current FAQ says the added SAQ A script-attack eligibility criterion applies to merchant pages containing embedded provider forms, not to specified redirects or fully outsourced email-link flows. It describes protective techniques or provider confirmation for the embedded case (PCI SSC FAQ 1588). This does not mean redirects need no protection. Another PCI SSC FAQ explains that merchant-managed redirect mechanisms and the systems controlling them must be protected against manipulation (PCI SSC FAQ 1439).

The practical boundary is therefore two-layered: where payment data flows, and what merchant-controlled components could change that flow.

Keep an evidence packet

For each checkout release, retain an architecture diagram, provider integration mode, hosted-field or redirect documentation, script inventory, approved domains, provider compliance evidence, responsibility matrix, and the date the acquirer confirmed the validation path. Record whether the merchant can see, log, or accidentally capture card fields. Check analytics, session replay, error logging, and support tools explicitly.

Document provider dependencies without treating the provider’s compliance as the merchant’s compliance. Assign owners for provider-status review, secret rotation, access removal, patching, script changes, and incident escalation. The payment acceptance launch checklist covers the broader operating controls; webhook signature handling covers server-to-server messages after checkout.

Review changes that reopen the boundary

A checkout that qualified for one validation path can change when a developer adds an address helper, coupon widget, analytics tag, support overlay, alternative payment element, custom card field, or new redirect mechanism. Create a release gate that asks:

• Did any element inside the payment page change origin?
• Can any new script affect the embedded payment experience?
• Did a log, proxy, or browser-monitoring tool gain access to payment data?
• Did DNS, hosting, authentication, or administrative ownership change?
• Is the provider still listed and validated for the services relied upon?
• Has the acquirer confirmed that the existing validation path remains appropriate?

Also rehearse compromise. Know how to disable checkout, preserve logs, rotate credentials, contact the provider and acquirer, and move customers to a safe status page without collecting payment details through improvised channels.

Hosted checkout is valuable precisely because it can move sensitive functions to a specialized provider. Treat that as a designed boundary with evidence and change control, not as a sentence in a sales deck.

Sources

• PCI SSC, payment-page origin and SAQ eligibility FAQ
• PCI SSC, SAQ A script eligibility FAQ
• PCI SSC, SAQ A merchant-system requirements FAQ