Under PCI DSS v4.0.1, how does an online store's choice of hosted payment page, embedded iframe or its own card form change its scope?

## The question PCI DSS asks of a checkout **PCI DSS v4.0.1** applies to systems that store, process or transmit account data *and* to systems that **could impact its security**. The standard gives an e-commerce example of the second kind: an entity whose infrastructure can affect how cardholder data is processed, "for example, via a web server that controls the generation of a payment form or page". Section 4 also lists **e-commerce (web) redirection servers** among systems that could impact the CDE. So the architectural question is not only "do our servers see the PAN?" but also "can our servers change what the shopper types the PAN into?". ## Three architectures compared | Design | Who receives the PAN | Store's position under PCI DSS | |---|---|---| | Own card form posted to the store's servers | The store | Web, application and database tiers are in the CDE; the full set of requirements applies | | Redirect to a processor-hosted payment page | The processor | The redirecting web server can impact security; the store's own page never hosts the card fields | | Processor form embedded in an iframe on the store's page | The processor | The store's page hosts the payment form, so 6.4.3 and 11.6.1 apply to its scripts | The standard's glossary defines a **payment page** as a web interface with form elements that capture account data, and it counts a form displayed "in an inline frame within a non-payment page" as a payment page. The store's surrounding page is not itself the payment page, yet, as the next section shows, requirements still reach it - which is why the iframe option is not a free pass. ## Requirements 6.4.3 and 11.6.1 for the page around the iframe **Requirement 6.4.3** requires that all payment page scripts loaded and executed in the consumer's browser are managed: - a method confirms each script is **authorized**; - a method assures the **integrity** of each script; - an **inventory** of all scripts is kept with a written business or technical justification for each. **Requirement 11.6.1** requires a **change- and tamper-detection mechanism** that alerts personnel to unauthorized modification of the **security-impacting HTTP headers and the script contents** of payment pages *as received by the consumer browser*. It runs at least weekly, or at a frequency set by a targeted risk analysis performed under Requirement 12.3.1. The applicability notes of both requirements draw the line for iframes: 1. They **apply** to scripts in the entity's webpage that includes a third-party service provider's (TPSP's) or payment processor's embedded payment page or form. 2. They **do not apply** to the entity for scripts *inside* the TPSP's embedded form; those are the TPSP's responsibility. 3. The entity should expect the TPSP to provide evidence that it meets the requirement, consistent with its PCI DSS assessment and **Requirement 12.9**. Both were a best practice until 31 March 2025 and are required since then. The guidance names techniques - a Content Security Policy that limits where scripts load from and where data may be sent, sub-resource integrity, synthetic monitoring of the rendered page - without mandating any one. ## What stays with the store in every option - **Service-provider management (Requirement 12.8):** a list of providers, written agreements, due diligence, monitoring their compliance status at least once every 12 months (12.8.4), and a record of which requirements each party owns (12.8.5). - **Validation paperwork:** how the store validates is set by its acquirer and the payment brands. The Self-Assessment Questionnaire types and their eligibility criteria live in the PCI SSC's SAQ documents, not in the standard, and they track these same design choices. - **Incident response:** Requirement 12.10.1 applies to every entity. ## Choosing - **Own form** gives full control of the checkout and the largest scope. - **Hosted page** gives the smallest footprint but hands the checkout experience to the processor. - **Iframe** keeps the store's look and feel, at the price of script governance on the surrounding page. Skimming attacks commonly work by injecting script into the checkout page, which is why v4.0 added requirements aimed at what the shopper's browser actually receives, not only at the store's servers.