PCI DSS 4.0 requirements 6.4.3 and 11.6.1 for online stores decide how a shop controls the scripts on its payment pages and how it notices when someone changes them. We prepare a store for both: a script inventory with justifications, a method to authorise each script and check its integrity, and a change-detection mechanism with alerts. You get working controls and the evidence your assessor or acquirer will ask for.
Why payment page scripts became a PCI requirement
Scripts on a checkout page run in the customer's browser and can read what the customer types, including card numbers. Attackers who change one script, or add one through a compromised plugin or tag manager, can copy card data while the payment still goes through normally. This is called e-skimming.
The PCI Security Standards Council responded with two requirements in PCI DSS v4.0. In March 2025 it published an information supplement, "Payment Page Security and Preventing E-Skimming", which explains them for merchants and service providers. In the Council's words, the aim is that payment page scripts are properly authorized, checked for integrity and monitored for tampering.
Requirement 6.4.3 and 11.6.1 at a glance
Both requirements apply to the payment page as it reaches the customer's browser. The table restates them in plain terms.
| Requirement | What it means for a store | Source |
|---|---|---|
| 6.4.3, authorisation | A method confirms each script on the payment page is authorised | PCI DSS v4.0.1 |
| 6.4.3, integrity | A method assures each script has not been altered | PCI DSS v4.0.1 |
| 6.4.3, inventory | All scripts are listed with a written business or technical justification | PCI DSS v4.0.1 |
| 11.6.1, detection | A mechanism alerts staff to unauthorised changes to security-impacting HTTP headers and script contents | PCI DSS v4.0.1 |
| 11.6.1, frequency | At least weekly, or at a frequency set by a targeted risk analysis | PCI DSS v4.0.1 |
| Effective date | Future-dated until 31 March 2025, required since | PCI SSC |
| SAQ A | Both removed from SAQ A in its January 2025 version; a script-attack eligibility criterion added | PCI SSC |
PCI DSS v4.0.1, published on 11 June 2024, is a limited revision. The Council states that it does not change the effective date of the new requirements, and it added applicability notes on how the script requirement applies.
Which stores are in scope
Any merchant whose website hosts the payment page, or whose page embeds a provider's payment form, has to deal with these requirements in some form. The Council's guidance addresses entities that take card payments through e-commerce, including through embedded iframes, and pages that can affect the security of those payments.
- Own payment page or direct post: 6.4.3 and 11.6.1 apply in full.
- Embedded iframe, SAQ A: the store confirms its site is not susceptible to script attacks, either with its own protections or with written confirmation from its PCI DSS compliant provider.
- Full redirect to the provider's hosted page: your acquirer and provider confirm which questionnaire applies; your own site still needs normal web security.
Your acquirer or the payment brands decide which validation applies to you. The Council itself states that it does not enforce compliance.
How we prepare a store
The work produces the controls and the documents that show they run. We start from the real payment page as a browser receives it, since tag managers and plugins often load scripts nobody listed.
- Script discovery. We record every script on each payment page, including scripts loaded by other scripts and tag managers.
- Inventory and justification. Each script gets an owner, a purpose and a written justification; unneeded ones go on the removal list.
- Authorisation and integrity. We configure a Content Security Policy for the payment pages and Subresource Integrity hashes where a script is static, or another method your platform supports.
- Change detection. We set up a mechanism that checks the received headers and script contents at least weekly and alerts the people you name.
- Evidence pack. Screenshots, configuration exports, the inventory and the alert test go into one folder for the assessor.
What you receive
You receive working script controls on your payment pages and the documents that prove they run.
- The payment page script inventory with owners and justifications.
- Configured authorisation and integrity controls, tested on staging and live.
- A working change- and tamper-detection mechanism with alert routing and a test alert.
- A short procedure: how to add a new script, who approves it, how the inventory is updated.
- The evidence pack for your SAQ or your assessor, plus a re-check after go-live.
What we need from you
We need administrator access to the shop platform and tag manager, contact with your payment provider, your current SAQ type or your assessor's contact, and a signed scope letter listing the payment pages.
Boundaries
We prepare controls and evidence. We are not a Qualified Security Assessor or an Approved Scanning Vendor, and we do not sign or file your Self-Assessment Questionnaire or Report on Compliance; your company and, where required, your assessor do that. Requirements outside the web layer, such as card data storage or network segmentation, stay outside this scope unless the scope letter adds them.
Risks of handling 6.4.3 and 11.6.1 alone or with a freelancer
A script list made by hand from the page source misses scripts injected by the tag manager at run time. A strict Content Security Policy written without testing can block the payment form on the day of a sale.
General chatbot advice often mixes PCI DSS v4.0 and v4.0.1 wording or ignores the SAQ A changes of 2025. A freelancer may set up a tool and leave no procedure for the next marketing tag. We test on the live payment flow, document each step and re-check after go-live.
Who does the work
Engagements are contracted with INNOVA CONSULT LTD., Ottawa, Ontario (Corporations Canada, Corporation Number 1522612). The team keeps its own servers and more than 80 websites under daily vulnerability checks. Paid detection tools, if you choose one, are billed at cost without vendor commissions.
Cost
A fixed price is set in the scope letter after a 30-minute call. It depends on the platform, the payment integration and the number of scripts on payment pages.
Related services
- Website security audit for the rest of the store.
- WordPress security for WooCommerce shops.
- DDoS and bot protection against card testing and cart abuse by bots.
- GDPR website security requirements for customer data beyond cards.
- Building or rebuilding a shop: online store development. All cybersecurity services.
Sources (checked 2026-10-23)
- PCI Security Standards Council, Just published: PCI DSS v4.0.1 (11 June 2024).
- PCI Security Standards Council, New information supplement: Payment Page Security and Preventing E-Skimming (10 March 2025).
- PCI Security Standards Council, Coffee with the Council: guidance for e-commerce requirements effective after 31 March 2025.
- PCI Security Standards Council, Document Library: PCI DSS v4.0.1 and SAQ A.
- W3C, Content Security Policy Level 3 and Subresource Integrity.
Maksym Stepanenko, founder of Marketing MIX. Last reviewed: 2026-10-23.