The payment page you did not think was in scope: 6.4.3 and 11.6.1

If your checkout redirects to a payment gateway, or embeds the gateway's form in your own page as an iframe, you have almost certainly been told the payment page is not yours. That is true of the form. It is not true of the page around it.

PCI DSS v4.0.1 places two requirements on that page — 6.4.3, script authorisation, integrity and inventory, and 11.6.1, change- and tamper-detection — and it does so in an applicability note most merchants have never read. Both were best practice until 31 March 2025. Since that date they are simply requirements.

There is also a change that has confused this boundary since April 2025: if you file SAQ A, the Council removed both from your questionnaire and put a single sentence in their place. That made the paperwork shorter and the attestation harder.

What the two requirements demand

6.4.3 is three obligations in one sentence — “All payment page scripts that are loaded and executed in the consumer's browser are managed as follows”:

• “A method is implemented to confirm that each script is authorized.”
• “A method is implemented to assure the integrity of each script.”
• “An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.”

11.6.1 requires a mechanism that alerts on “unauthorized modification (including indicators of compromise, changes, additions, and deletions) to 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 an interval you justify in a targeted risk analysis performed under Requirement 12.3.1.

A third obligation carries the same date and is routinely missed. Requirement 12.10.5 gained a bullet covering “the change- and tamper-detection mechanism for payment pages”, so the alerts 11.6.1 produces have to be inside the incident response plan rather than arriving in a mailbox nobody owns.

The applicability note is the whole argument

Both requirements carry the same note, near-verbatim. For 6.4.3:

“This requirement also applies to scripts in the entity's webpage(s) that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frames or iframes). This requirement does not apply to an entity for scripts in a TPSP's/payment processor's embedded payment page/form … Scripts in the TPSP's/payment processor's embedded payment page/form are the responsibility of the TPSP/payment processor to manage.”

The boundary runs the opposite way to intuition. What is inside the iframe is the gateway's problem. What is on your page — the one hosting the iframe — is yours, and the standard says so in terms. 11.6.1 draws the identical line for tamper detection.

What counts as a script, and what counts as the payment page

Both terms are defined, and both definitions do scoping work.

A payment page is “a web-based user interface containing one or more form elements intended to capture account data”, and it may be rendered as “a document or component displayed in an inline frame within a non-payment page”. So the iframe is the payment page, and your checkout is the non-payment page carrying it. That is exactly why 6.4.3 needed an applicability note to reach your page at all — without it, your page falls outside the definition.

Payment page scripts are “any programming language commands or instructions on a payment page that are processed and/or interpreted by a consumer's browser”, and the definition closes by excluding presentation: “neither markup-languages (for example, HTML) or style-rules (for example, CSS) are programming languages.” The inventory is a list of executing code, not a list of assets.

What changed for SAQ A in April 2025

The Self-Assessment Questionnaire Instructions and Guidelines were revised to v4.0.1 r1 in April 2025. Its own Document Changes table records it in one line: “Removed Requirements 6.4.3 and 11.6.1 from section ‘Importance of new requirements added to SAQ A for PCI DSS v4.x.’” That section now names only 11.3.2 and 11.3.2.1, the external scanning pair.

In their place the same revision added an eligibility criterion for e-commerce merchants filing SAQ A:

“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).”

Look at what the swap does. Answering 6.4.3 and 11.6.1 means describing a mechanism: here is the inventory, here is the integrity method, here is the detection cadence and its result. The eligibility criterion asks for none of that. It asks you to have already reached the conclusion, and it sits above the signature rather than inside the questionnaire. There is no testing procedure attached to an eligibility criterion — which means the evidence that supports it is whatever you would want in front of you if your acquirer asked how you confirmed it. In practice that is the same inventory and the same detection output the two requirements would have asked for.

And the removal narrows one validation form, not the standard. 6.4.3, 11.6.1 and 12.10.5 remain PCI DSS requirements. Anything filed on SAQ A-EP or SAQ D, and any assessment written up as a Report on Compliance, answers all three in full.

Where SAQ A stops

The line is drawn on origin, and the Guidelines state it flatly: “If any element of a payment page delivered to consumers' browsers originates from the merchant's website, SAQ A does not apply; however, SAQ A-EP may be applicable.”

The full eligibility picture is a separate question, covered in which SAQ applies to you. What matters here is that an A-EP merchant gets no relief from the applicability note, because the Guidelines add that “for the purposes of SAQ A-EP, PCI DSS requirements that refer to the ‘cardholder data environment’ are applicable to the merchant website(s)”. The website is the environment.

The evidence

Two boundary artefacts sit alongside them. Requirement 12.8.5 requires a record of which requirements each TPSP manages, which you manage, and which are shared — and 6.4.3 and 11.6.1 split across that line by construction, which makes them the likeliest pair for both sides to assume the other holds. Requirement 12.9.2 is the leverage: a TPSP must supply its compliance status and its responsibility split on request. The guidance on 6.4.3 says the same thing from your side — you “should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement”.

One caution the standard supplies itself, on the detection mechanisms it lists for 11.6.1: “the use of any one mechanism is not necessarily a full detection and reporting mechanism.”

Why this lands hardest on an Indian checkout

Two structural reasons, neither of them about market size.

First, the redirect and the embedded gateway form are the two implementations the Council singles out as SAQ A eligible — which makes them precisely the implementations merchants adopt in order to stay on SAQ A. The merchants most convinced they carry nothing are the ones carrying these two requirements. That is the sharp edge of “we use a payment gateway, so PCI does not apply to us”, and it survives every architectural move that reduced your account-data footprint, including tokenisation.

Second, the page hosting the iframe is usually the most heavily instrumented page on the site: analytics, remarketing pixels, chat, A/B testing, consent management, fraud scoring. Every one is a script in the 6.4.3 inventory, most were added by someone outside engineering, and several load further scripts of their own once the page is live.

Which of these you carry, and for which pages, is settled by reading the checkout as a browser actually receives it rather than by reading the gateway contract. That reading is the opening move in PCI DSS scoping and readiness work, and it costs considerably less than discovering the answer partway through validation.