PCI DSS 4.0.1: New Payment Page Script Rules
Open your browser's dev tools on your own checkout page right now and count the scripts loading. A live chat widget. Two analytics tags. An A/B testing platform. A retargeting pixel someone in marketing added eighteen months ago and never removed. Most US B2B and wholesale sellers running a checkout page have never inventoried this list — and as of March 31, 2025, PCI DSS 4.0.1 requires them to.
Requirements 6.4.3 and 11.6.1 are the two most operationally disruptive additions in PCI DSS 4.0.1, and they're aimed squarely at the payment page, not the back-office network perimeter PCI has traditionally policed. If your team hasn't touched this yet, your next PCI assessment is where you find out — and self-assessment questionnaires no longer let ecommerce merchants skip it.
What Changed: Requirements 6.4.3 and 11.6.1
Requirement 6.4.3 — Every Script Needs a Paper Trail
6.4.3 requires three things for every script that executes on your payment page, including scripts you didn't write:
A documented inventory. Every script gets logged with its source, its purpose, and who authorized it — this covers payment scripts, but also chat widgets, analytics, and testing tools that happen to load on the same page.
Integrity verification. You need a technical mechanism that detects when a script has been altered — Subresource Integrity hashes, a Content Security Policy with nonce-based restrictions, or a third-party script-monitoring service.
Business justification. Each script needs a written reason it belongs on a checkout page. "Marketing wanted it" is not a justification a QSA will accept.
Requirement 11.6.1 — Detection, Not Just Documentation
11.6.1 is the active half of the pair: a mechanism that monitors HTTP security headers and payment page content for unauthorized changes, with alerts reviewed at least weekly. Passive approaches — waiting for a customer to report something odd, or relying on general error monitoring — don't satisfy the requirement. The standard calls for tools like CSP violation reporting, synthetic user monitoring, or tamper-resistant embedded scripts.
Why the Council Added This
Both requirements target Magecart-style e-skimming: attackers inject malicious code into a payment page or into a third-party script that page loads, and card data is stolen directly from the customer's browser before it ever reaches your server. British Airways and Ticketmaster are the two most-cited breaches behind this rule change, and the mechanism is the same reason it's hard to catch — the exfiltration happens client-side, so your server-side monitoring sees nothing wrong. Attackers have been documented staying undetected for weeks to months.
What do PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 require?
PCI DSS 4.0.1's requirements 6.4.3 and 11.6.1, mandatory since March 31, 2025, require ecommerce merchants to maintain a documented, justified inventory of every script running on the payment page with integrity verification (6.4.3), and to actively monitor that page's headers and content for unauthorized changes at least weekly (11.6.1) — closing the gap Magecart-style card-skimming attacks exploit.
What This Means for US B2B and Wholesale Sellers
Established brands running a wholesale portal or a B2B checkout alongside a D2C storefront tend to have the most script sprawl, not the least — years of marketing tools, sales enablement widgets, and integration middleware accumulate on pages nobody revisits once they work. That makes the 6.4.3 inventory exercise bigger than it looks, and it makes 11.6.1's ongoing monitoring a real operational commitment, not a one-time fix.
This also applies more broadly than the standalone checkout page many teams picture. If your B2B portal generates quotes that route through a hosted payment page, or your wholesale ordering flow redirects to a third-party processor's checkout, that page is still in scope. Assessors treat any page that collects or transmits cardholder data as part of the payment flow, whether it's on your domain or embedded through an iframe.
Who This Applies To
6.4.3 and 11.6.1 apply to merchants using SAQ A-EP and SAQ D self-assessment questionnaires — broadly, any merchant whose payment page is scripted, customized, or partially hosted rather than a fully outsourced, unmodified third-party redirect. Merchants on the simpler SAQ A track were given a narrower path: as of the same March 2025 transition, SAQ A requires a self-attestation that the site isn't susceptible to script-based attacks, rather than the full 6.4.3/11.6.1 control set. Knowing which SAQ category your store actually falls into — not which one you assumed — is the first thing worth confirming before scoping the work.
Getting Compliant: The Practical Path
Start with a full script audit on every page in the payment flow, not just the final checkout step — redirects and embedded iframes count. Assign an owner and a written justification to each script that survives review; anything without one gets removed. Implement CSP headers with SRI hashing on what remains, then stand up weekly change monitoring with alerting that a real person reviews, not a dashboard nobody opens.
The most common failure mode isn't technical — it's organizational. Teams implement the CSP headers and the SRI hashes, treat that as "done," and never assign ownership of the weekly alert review 11.6.1 requires. Six months later the inventory is stale, a new script has been added without justification, and the monitoring tool has been generating alerts nobody reads. Compliance here isn't a sprint with a finish line; it's a standing process with a named owner, reviewed on a cadence, the same way you'd treat PCI network segmentation or key rotation.
This is the kind of requirement that's easy to under-scope internally, because it touches marketing tags as much as it touches security infrastructure — which is exactly why it keeps surfacing as a finding in 2026 assessments for merchants who thought they were done with PCI DSS 4.0.1 after the initial rollout.
MnT Future builds managed commerce platforms with PCI DSS v4.0.1 compliance — along with ADA/WCAG accessibility and multi-state sales tax — engineered in from the start, not bolted on before an audit. If you want a clear picture of where your checkout page actually stands against 6.4.3 and 11.6.1, book a free strategy session and we'll walk through it with you.