PCI DSS for E-commerce: Payment Page Scripts (6.4.3 & 11.6.1)

PCI DSS requirements 6.4.3 and 11.6.1, often shortened to PCI 6.4.3 and PCI 11.6.1, protect online checkouts from digital skimming. Requirement 6.4.3 says every script that runs on a payment page in the customer’s browser must be authorised, have its integrity assured and be listed in an inventory with a written justification. Requirement 11.6.1 says you must detect unauthorised changes to the payment page’s scripts and security-impacting HTTP headers, and alert on them at least weekly. Both have been mandatory since 31 March 2025 for merchants that validate with SAQ A-EP, SAQ D or a Report on Compliance.

This guide explains what the two requirements mean in practice, who they apply to, the evidence an assessor will ask for, and the other PCI DSS v4.0.1 controls that matter most to online retailers.

Key takeaways

• Both target Magecart-style skimming: 6.4.3 is about managing payment page scripts; 11.6.1 is about detecting changes to them.
• Both apply to SAQ A-EP, SAQ D and ROC merchants, and to service providers that host payment pages.
• SAQ A merchants no longer have the two requirements, but those that embed a provider’s payment form must confirm their site is not susceptible to script attacks.
• Your checkout integration largely decides which SAQ you use and how much is in scope.
• The hardest part is usually organisational: marketing and analytics tags added outside IT.

What do PCI DSS 6.4.3 and 11.6.1 require?

Digital skimming attacks inject malicious JavaScript into checkout pages to steal card details as customers type them. The two requirements work together against that threat.

The full wording and guidance are in PCI DSS v4.0.1, available from the PCI Security Standards Council document library.

What is a Magecart attack?

A Magecart attack is digital skimming: criminals inject malicious JavaScript into an online checkout so that card details are copied as customers type them and sent to a server the attackers control, while the payment goes through as normal. The name comes from early attacks on Magento stores, but any e-commerce platform can be hit. The stolen details are then used for card-not-present fraud at other merchants.

The malicious script usually gets onto the page in one of two ways:

• The site itself is compromised, for example through an unpatched platform, plugin or extension, or a stolen administrator password.
• A third-party script is compromised at source, such as analytics, chat, reviews or a tag manager, so the change happens on someone else’s server and your own code never changes.

Because the code runs in the customer’s browser, server-side controls such as a web application firewall or file integrity monitoring on your web server may not see it, and neither you nor your customers notice anything wrong. That is why client-side security matters: 6.4.3 makes you know and approve every script on the payment page, and 11.6.1 makes you detect when what the browser receives changes.

The consequences can be serious. The UK Information Commissioner’s Office fined British Airways £20 million in October 2020 after card details entered on its website in 2018 were copied to an attacker-controlled domain without interrupting bookings (ICO penalty notice).

Who has to comply with 6.4.3 and 11.6.1?

It depends on how your checkout collects card details.

If you are unsure where you sit, our guide to PCI SAQ A and SAQ A-EP explains the distinction in detail, and our free PCI compliance check suggests your likely SAQ.

What changed for SAQ A in January 2025?

The PCI SSC revised SAQ A so that it no longer includes 6.4.3 and 11.6.1. In their place is an eligibility criterion: the merchant confirms that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

A PCI SSC FAQ published in February 2025 narrowed who this affects. The criterion applies to merchants whose own web page embeds a provider’s payment form, such as an iframe. It does not apply to merchants that redirect customers to the provider’s payment page or fully outsource payments. An embedding merchant can meet it in one of two ways:

• Protect the page itself, using techniques like those in 6.4.3 and 11.6.1, deployed by you or a third party.
• Rely on the provider, with written confirmation from a PCI DSS compliant payment provider that its embedded solution, implemented as instructed, protects your page from script attacks.

That is not a free pass. To confirm it honestly, you need to know what scripts run on the page that hosts the payment form and how your provider protects its embedded form. Many SAQ A merchants still adopt a script inventory and a Content Security Policy because it is the simplest way to support the confirmation.

What evidence do assessors expect for PCI 6.4.3 and 11.6.1?

A QSA or your acquirer will expect to see the process working, not just a policy. This is the evidence they typically ask for:

The PCI SSC’s own guidance on both requirements, the information supplement Payment Page Security and Preventing E-Skimming, sets out approaches for merchants and service providers. It does not add to the requirements, but assessors know it well.

Where your page embeds a payment provider’s iframe, the requirement applies to the scripts on your page; scripts inside the provider’s iframe are the provider’s responsibility.

How do you comply with 11.6.1?

You need a mechanism that sees the payment page as the customer’s browser receives it and tells you when scripts or security-impacting headers change without authorisation. Options include commercial client-side monitoring services, Content Security Policy reporting combined with alerting, and synthetic checks that load the page and compare it against an approved baseline.

Run the check at least weekly, or at a frequency justified by a documented targeted risk analysis. Our guide to the PCI DSS targeted risk analysis explains how to set and defend a different frequency. Whatever you choose, make sure alerts reach someone who will act on them.

Which other PCI DSS requirements matter for online retailers?

• Web application protection (6.4.2). Public-facing web applications need an automated technical solution, such as a web application firewall, that continually detects and prevents web-based attacks.
• Patching (6.3.3). Critical security patches within one month of release. E-commerce platforms and plugins are frequent targets.
• Multi-factor authentication (8.4.2). MFA for all non-console access into the cardholder data environment, including hosting panels, platform admin consoles and deployment tools that can change the payment page.
• External scans (11.3.2). A quarterly ASV scan is required even under SAQ A, for the site that hosts or redirects to the payment page.
• Penetration testing (11.4). Annual and after significant change for SAQ A-EP, SAQ D and ROC merchants. PCI penetration testing should include the checkout and account areas.
• Service providers (12.8). A list of payment and hosting providers, written agreements, a record of which requirements each manages, and an annual check of their compliance status.

How can an e-commerce business reduce PCI scope?

The less card data you touch, the less there is to protect and assess.

• Use hosted payment pages or iframes wherever the customer experience allows.
• Tokenise stored card details so repeat payments and refunds use tokens from your provider.
• Keep card data out of other channels. Do not let customer service take card numbers by email or chat, and check logs and support tools.
• Separate your payment environment from the rest of your network if you do handle card data directly.

How do you prepare your checkout for validation?

1. Map your payment flows, including phone orders, refunds and manual processes.
2. Confirm the right SAQ, or whether a ROC is needed.
3. Build the script inventory and bring marketing, analytics and web teams into the approval process.
4. Deploy change detection for 11.6.1 and prove alerts are handled.
5. Work through a PCI compliance checklist for everything else in your SAQ, starting with controls that need a track record, such as quarterly scans.
6. Test the site. Web application penetration testing finds checkout flaws that scanners miss, and website penetration testing also covers your shop platform, its plugins and the admin area.
7. Complete and submit your SAQ or ROC and Attestation of Compliance to your acquirer.

Getting help

Most online retailers can keep PCI compliance for e-commerce manageable with the right checkout design and a firm grip on their scripts. Sovereign Secure is a PCI SSC-approved Qualified Security Assessor company. A PCI DSS consultant from our team can confirm which SAQ applies and review your payment page controls, and we carry out the full PCI compliance audit where a ROC is required. Advisory and assessment work are kept separate, as the PCI SSC expects of a QSA company.

If you run a Magento or Adobe Commerce store, our guide to Magento PCI compliance covers the platform-specific checks. Otherwise, start with the free PCI compliance check to confirm your likely SAQ, then contact us to talk through your checkout.