Reference
PCI DSS 6.4.3 and 11.6.1, in plain English.
The two PCI DSS v4.0.1 requirements about the scripts on your payment pages: what they ask for, whether they apply to you, and what to do on Magento, Shopify, BigCommerce and WooCommerce. Checked 9 November 2026.
Know every script, spot every change.
Both have applied since 31 March 2025. They exist because card skimming works by getting a script onto the payment page.
6.4.3 Manage every script
Every script that runs on a payment page is authorised, has a written business reason, and is checked to be the script it should be (for example with integrity checks). In practice, a maintained list of every script and why it's there.
11.6.1 Detect changes
Unauthorised changes to payment pages, and to the security headers they're served with, are detected and alerted, at least once a week or as often as your risk assessment sets.
Including other companies' scripts
Analytics, tag managers, chat, reviews and marketing pixels all count if they run on the payment page. So do scripts added through a tag manager after the page loads.
Does it apply to you?
It depends on how you take card payments, and so which self-assessment questionnaire (SAQ) you complete. Your acquirer or QSA has the final word.
- Card details entered on your own pages (your checkout collects or touches card data): 6.4.3 and 11.6.1 apply to your payment pages in full.
- A payment provider's iframe or redirect (SAQ A): since the January 2025 revision of SAQ A, you don't answer 6.4.3 and 11.6.1 directly. Instead, to be eligible for SAQ A you confirm your site is not susceptible to attacks from scripts that could affect your ecommerce systems. The PCI Security Standards Council's FAQ 1588 explains how to meet that: put the 6.4.3 and 11.6.1 controls on the page that hosts the payment iframe, or get confirmation from your payment provider that its solution protects against script attacks.
- Payment providers themselves must still meet 6.4.3 and 11.6.1.
Either way, the practical answer is much the same: know every script on the pages around your checkout, control who can add them, and notice when they change.
What it means on your platform.
Magento and Adobe Commerce
The checkout is yours, and so is every script on it. From 2.4.7, Magento adds Subresource Integrity to its own scripts on payment pages and enforces its Content Security Policy there; earlier releases only report. Third-party extensions and tag manager scripts still need managing.
Shopify and Shopify Plus
Shopify runs and secures its checkout. The apps, pixels, checkout extensions and theme scripts you add around it are yours to list and manage.
BigCommerce
BigCommerce runs the hosted checkout. Scripts you add through Script Manager, apps and your theme are yours, so keep Script Manager to the scripts you can justify.
WooCommerce and custom builds
The whole checkout is yours unless card fields come from your payment provider. Either way, the pages around the payment form need managing.
Free tool
Do you know every script on your checkout?
List every script on the way to your checkout and who it belongs to, with a score out of 100. Free, in seconds.
Five steps that cover most of it.
List every script on the payment pages
Each script's source, owner and reason for being there. Our free checkout script checker gives you a starting list.
Keep tag managers off payment pages
Or limit who can publish to them and review every change, because a tag manager can add a script without a developer.
Enforce a Content Security Policy
A policy that lists the sources scripts may load from, with nonces or hashes for inline code. Run it in report-only mode first, then enforce it.
Add integrity checks to fixed files
Subresource Integrity on scripts that don't change, so a file changed at its source won't run.
Monitor for changes
Check the payment pages and their headers for new or changed scripts, with an alert, at least weekly.
What people ask us.
Is this the same as being PCI compliant?
No. 6.4.3 and 11.6.1 are two of many PCI DSS requirements. Whether you comply is assessed through your self-assessment questionnaire or by a Qualified Security Assessor (QSA), and your acquirer decides which applies.
We use a payment provider's hosted payment page. Are we exempt?
Not quite. If you complete SAQ A, you no longer answer 6.4.3 and 11.6.1 directly, but you must confirm your site isn't susceptible to script attacks that could affect your ecommerce systems. Check with your provider and your acquirer which way you meet that.
How often do we need to check for changes?
11.6.1 says at least weekly, or as often as your targeted risk analysis sets. Many merchants check continuously, with an alert when something changes.
Do analytics and marketing scripts count?
Yes, if they run on a payment page. That's often where the problems are, so many merchants remove them from the checkout altogether.