What Is Req 6.4.3 and Why Is It Shutting Down Merchants?

There's a requirement sitting inside PCI DSS 4.0.1 that is quietly failing more e-commerce merchants than any other — and most of them have no idea it applies to them. It doesn't require expensive hardware. It doesn't require a security team. What it requires is something most merchants have never thought to do: know exactly what JavaScript is running on your checkout page.

That's Requirement 6.4.3. It became mandatory on March 31, 2025. And it's the reason merchants are losing their ability to process cards.

What Requirement 6.4.3 Actually Says

The full text of Requirement 6.4.3 from PCI DSS 4.0.1 requires that all payment page scripts loaded and executed in the consumer's browser are managed as follows:

Three things. Every script. On every payment page. No exceptions for scripts you didn't write, scripts loaded by your platform, or scripts added by your marketing team six months ago and forgotten.

Why Merchants Are Failing This — and Losing Processing

The honest answer is that Requirement 6.4.3 asks merchants to do something they've never had to do before: treat their checkout page's JavaScript the same way a bank treats financial transactions — with full documentation, authorization, and audit trail.

Most merchants have never counted the scripts on their checkout page. When we scan them, the results are sobering.

The consequences of failing 6.4.3 aren't theoretical. Acquiring banks — the financial institutions that give merchants the ability to accept card payments — are increasingly requiring merchants to demonstrate compliance, not just attest to it. A formal QSA assessment that finds 6.4.3 failures can result in:

• A failed compliance assessment requiring immediate remediation
• A remediation window — typically 30–90 days — during which processing may be restricted
• Fines of $5,000–$100,000 per month for continued non-compliance
• In severe cases, suspension of card processing privileges

What Pages Are Actually In Scope?

This is where a lot of merchants get false confidence. Requirement 6.4.3 applies to payment pages — defined as any page that is rendered to or accessible by the end user's browser and that either accepts cardholder data or contributes to the transaction flow.

In practice, that means:

The practical implication: a merchant who runs a "clean" homepage scan but has 18 third-party scripts loading on their checkout page — with no inventory, no justification, and no integrity checks — is failing 6.4.3 completely, regardless of what the homepage shows.

What Counts as a "Script" Under 6.4.3?

More than most merchants realize. The requirement covers every JavaScript element that executes in the browser on a payment page:

External scripts

Any <script src="..."> tag loading JavaScript from an external domain. This includes Google Tag Manager, Google Analytics, Facebook Pixel, Stripe.js, Hotjar, Intercom, LiveChat, Klaviyo — every one of them.

Inline scripts

JavaScript written directly into the HTML of the page between <script> tags. These need to be inventoried and their integrity verified just like external scripts.

Scripts loaded by scripts

This is the one that catches most merchants. Google Tag Manager doesn't just load one script — it dynamically injects whatever tags are configured inside it. Each of those injected scripts is also in scope. A single GTM container can load dozens of third-party scripts your team may not even know are active.

Event handler scripts

Inline event handlers like onclick="...", onsubmit="..." on form fields — these execute in the browser and fall within scope.

The Three Things You Actually Have to Do

1. Inventory — know what's there

Build a complete list of every script that loads on each in-scope page. This is not a one-time exercise — scripts change constantly. Marketing installs a new pixel. A developer updates a third-party library. A vendor silently changes their CDN URL. Your inventory needs to reflect the live state of your checkout pages.

At minimum, your inventory should capture for each script:

• Script source URL (or "inline" for embedded scripts)
• Script purpose / what it does
• Which pages it loads on
• Date first detected / added
• Authorized by (name and role)
• Date of last review
• Integrity hash (SRI) or equivalent control

2. Authorization — justify every script

For each script in your inventory, you need a documented business justification. This doesn't need to be a formal legal document — but it does need to exist and be defensible. "Marketing uses it" is not sufficient. "Google Analytics — provides session and traffic data used by the marketing team for campaign performance reporting, approved by [name] on [date]" is what you're aiming for.

Any script without a documented justification is an unauthorized script. Under 6.4.3, an unauthorized script on your payment page is a finding.

3. Integrity — verify nothing changed

This is where most merchants get stuck. The standard requires a method to confirm that scripts haven't been tampered with. The most common technical implementation is Subresource Integrity (SRI):

With an SRI hash in place, the browser will refuse to execute the script if its content has changed from the expected hash — which is exactly what happens when a Magecart attacker compromises a third-party library to inject card-stealing code.

However, SRI has limitations: it doesn't work well with dynamically versioned scripts (like many CDN-hosted libraries that update frequently), and it cannot cover scripts injected by tag managers. Those require additional controls — which is why Requirement 11.6.1's tamper detection mechanism exists alongside 6.4.3.

How to Actually Build Your Script Inventory

Here's a practical approach that works for merchants of any size, from a Shopify store to a custom-built checkout:

1. 1
   Scan your checkout pages — all of them

   Open your browser's developer tools (F12), go to the Network tab, filter by "JS", and load your checkout page from scratch. Every script that appears is in scope. Do this for checkout, cart, login, account, and any payment page. Screenshot or export the results. A client-side scanner like ClientSideIntel's Deep Scan will do this automatically and give you a structured list.
2. 2
   Open your tag manager and audit every tag

   If you use GTM, Tealium, or similar — log in and export a full list of tags configured in the container. For each tag, check: Is it firing on checkout pages? Who added it? When? Why? Tags that have no clear owner or haven't been reviewed in over a year are candidates for removal or at minimum require fresh authorization.
3. 3
   Build your inventory spreadsheet

   Create a document — a simple spreadsheet works — with one row per script. Capture source URL, purpose, pages loaded on, who authorized it, and when. This is your living compliance artifact. It needs to be updated whenever scripts change.
4. 4
   Remove or document every unknown script

   Any script you can't identify or justify needs to be removed or escalated immediately. Unknown scripts on payment pages are exactly the kind of exposure that enables Magecart attacks — and they're an automatic finding under 6.4.3. If you find scripts you don't recognize, treat it as a potential security incident until proven otherwise.
5. 5
   Add SRI hashes where possible, and implement a CSP

   For static external scripts, add SRI hashes. For your checkout pages, implement a Content Security Policy (CSP) that explicitly allowlists the script sources permitted to load. A properly configured CSP prevents any unauthorized script from executing — even if someone manages to inject it into your page.
6. 6
   Schedule regular reviews

   Your script inventory is not a one-time project — it's an ongoing control. Requirement 6.4.3 implies continuous management. Set a calendar reminder to review and re-verify your inventory at least quarterly, and establish a process so that any new script added to a payment page requires documented authorization before it goes live.

The Most Common Mistakes

Scanning only the homepage. The homepage is almost never in scope for 6.4.3. Your checkout, cart, login, and payment pages are. Run your inventory on those.

Assuming Shopify or WooCommerce handles it. They don't. They handle server-side payment processing. Every script your storefront loads in the browser — including the ones added by your apps, themes, and marketing integrations — is your responsibility.

Ignoring tag manager contents. A tag manager is not one script. It's a vehicle for an unlimited number of scripts. If your GTM container fires on checkout, your inventory must account for every tag inside it.

Treating inventory as a one-time project. Scripts change constantly. A new marketing tool gets installed. A vendor updates their CDN. A developer pushes a fix. Your inventory needs a process, not just a document.

No formal authorization process. The standard requires documented justification. "I know we need it" is not documentation. Assign ownership, capture approval, record the date.

Your Next Step

The fastest way to understand your current exposure is to scan your checkout pages and see exactly what's loading. Most merchants who do this for the first time are surprised — not by the finding that they have scripts, but by how many they have and how few they can actually identify.

ClientSideIntel's Deep Scan covers your checkout, cart, login, and payment pages and delivers a full script inventory in PDF format — the same format you'd present to a QSA. If you're approaching a compliance review, it's the fastest way to know where you stand before an assessor tells you.