← All articles · April 22, 2026 · CheckoutProof

PCI DSS v4.0 Requirement 6.4.3 for WooCommerce Merchants: A Plain-English Guide

If you’re running a WooCommerce store and your acquirer or auditor mentioned Requirement 6.4.3, this is what they’re talking about — and what you actually need to do about it. No acronym soup, no lawyer language, no “consult your QSA” punts.

This guide is written for the person who runs the store. You don’t need to know what a Cardholder Data Environment is. You need to know what to put on the page, what to write down, and what to monitor — so the next time someone asks you about PCI 6.4.3, you can answer.

What 6.4.3 actually says

Strip out the standards-speak and Requirement 6.4.3 says three things:

1. You need a list of every JavaScript that runs on your payment page.
2. For each script, you need a written reason it’s there and the name of who authorized it.
3. You need a way to prove each script hasn’t been tampered with since you authorized it.

That’s it. Three things: an inventory, an authorization, and an integrity check.

The “payment page” part matters. 6.4.3 only applies to the page where the customer enters their card number — your checkout. Not your homepage, not your cart, not your category pages. Just checkout.

What changed in v4.0

Older versions of PCI DSS (3.x) treated client-side script monitoring as a “good idea.” Version 4.0, finalized in March 2022 and revised to 4.0.1 in June 2024, made it a hard requirement.

The rule became mandatory and assessable on March 31, 2025. If you’re being assessed today and you don’t have an answer for 6.4.3, you fail.

The companion rule, Requirement 11.6.1, says you also need to automatically detect and alert on changes to your payment page. At least weekly. So 6.4.3 is “know what’s there”; 11.6.1 is “tell me when it changes.”

Why this lands hardest on WooCommerce

If you run a Shopify store on Shopify Payments, Shopify’s managed checkout absorbs 6.4.3 for you. The script-bearing page lives on Shopify’s domain, and Shopify is responsible for what runs there.

If you run a WooCommerce store, the payment page is yours. You own the WordPress site. You picked the theme. You installed the plugins. The Stripe iframe (or PayPal redirect, or whatever) loads inside a page that your WordPress site renders. Every script on that page is your responsibility.

That includes:

• Your theme’s scripts.
• Plugins you installed (analytics, A/B testing, popups, chat widgets, abandoned-cart recovery, security plugins, anything).
• Whatever the payment processor’s plugin loads.
• Anything those scripts then load (third-party tag manager → fires Facebook pixel → loads other Facebook scripts).

A typical WooCommerce checkout page runs 15–40 scripts. Most merchants don’t know that, and most don’t know which of them is which.

What “an inventory” actually looks like

The auditor doesn’t want a sentence like “we use Stripe and Google Analytics.” They want a structured list, one row per script, with at minimum:

• The script’s URL (or “inline” if it’s embedded directly in the HTML).
• A short description of what it’s for.
• Why your business needs it.
• Who in your organization authorized it.
• A cryptographic hash of the script’s content (more on this below).

For a 25-script checkout page, this is a 25-row table. It can live in a spreadsheet, a Notion doc, or a JSON file in your repo. The format doesn’t matter; the existence of it does.

This is not a “set it once and forget” exercise. The list has to be updated whenever a script changes. That’s why most merchants need automation; we’ll get there.

What “proof of integrity” actually looks like

The most common technical control is Subresource Integrity (SRI). You add an integrity attribute to a <script> tag. The browser checks the script’s content against the hash you specified, and refuses to run it if it doesn’t match.

<script
  src="https://example-cdn.com/widget.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

If the script gets modified — by an attacker compromising the CDN, by your vendor pushing a new build, or by a malicious browser extension trying to MitM the response — the hash no longer matches and the browser refuses to execute it.

SRI is free, supported in every modern browser, and gives you a hard cryptographic guarantee that the code running on your page is exactly what you authorized.

Three caveats:

• SRI works for static scripts only. If your vendor’s JS file changes daily, you can’t pin a hash to it. You either ask the vendor to publish versioned URLs (/widget-1.4.2.js) or you use a different control.
• SRI doesn’t help with inline scripts. A <script>console.log('hi')</script> block in your HTML has no integrity attribute. For inline scripts, you control them directly — auditors generally accept “we author this, it’s checked into version control” as proof.
• SRI doesn’t catch dynamic injection. If one of your authorized scripts then loads another script (for example, a tag manager loading a third-party pixel), SRI on the first script doesn’t follow that chain.

That last point is why 6.4.3 also expects a Content Security Policy (CSP) with a report-to directive. CSP tells the browser “only load scripts from these specific domains,” and forces the browser to send you a report any time something tries to load from a domain you didn’t allow.

CSP is the safety net. SRI is the lock on the front door.

How to actually get there: the WooCommerce checklist

If you’re starting from zero, here’s what to do in order. Plan on a long weekend if you’re doing it by hand.

1. Take a real inventory of your checkout page.

Open your checkout page in Chrome. Open DevTools → Network tab → filter by JS. Refresh the page. Note every script that loads. Then check View Source for inline <script> blocks. You’ll find 15–40 entries. Write them down.

(Or run our free scanner and skip the manual step. It does this in 10 seconds.)

2. For each script, write down what it’s for and who authorized it.

This part is annoying but necessary. For each entry on your inventory, fill in:

• What is this for? (“abandoned cart popup”, “Stripe Elements card form”, “Google Analytics”, “the abandoned-cart vendor’s recommendation widget”, etc.)
• Why does the business need it? (one sentence; this is the auditor’s “approved business justification”)
• Who authorized it? (your name, the marketing manager’s name, whoever)

Anything you can’t justify, delete. Half the scripts on a typical WooCommerce checkout are vestigial — installed once for an experiment, never removed. The single most effective thing you can do for 6.4.3 compliance is uninstall the WordPress plugins you no longer use.

3. Add SRI hashes to every external script you control.

For scripts loaded from a CDN with stable versioned URLs, compute the SHA-384 hash and add the integrity attribute. WooCommerce plugins that bundle their own JS usually serve from versioned URLs (e.g., /wp-content/plugins/foo/assets/foo-1.2.3.js); those are good candidates.

If a plugin doesn’t load from a versioned URL, you have two choices: ask the vendor, or switch plugins.

4. Add a Content Security Policy to your checkout page.

A starter CSP for a WooCommerce checkout that uses Stripe Elements looks roughly like this:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'unsafe-inline' https://js.stripe.com https://www.googletagmanager.com;
  frame-src https://js.stripe.com https://hooks.stripe.com;
  connect-src 'self' https://api.stripe.com;
  report-to /csp-report;

Yours will be different — it depends on which scripts your inventory turned up. The point is: you list the domains explicitly, and anything not on the list gets blocked.

CSP is set as an HTTP header. The cleanest way in WordPress is via your hosting provider’s edge proxy (Cloudflare Page Rules, for example) or via a WordPress plugin that adds headers.

5. Set up monitoring.

Per Requirement 11.6.1, you need to detect changes weekly. The simplest answer is a periodic scan of your checkout page that compares today’s script list against last week’s. If anything changed, alert.

What auditors actually accept as evidence

When you’re up for assessment, a QSA — or, if you’re filling out a self-assessment questionnaire, the QSA who reviews your SAQ — will want:

• The written script inventory, dated.
• A copy of the CSP header you serve on the checkout page.
• For SRI, evidence that the browser is enforcing the integrity check (a CSP report from when you intentionally tampered with a script and confirmed the browser blocked it is gold-standard).
• A monitoring report showing scans were run weekly for the last quarter, and that any changes were investigated and re-authorized.

Keep all of that in one folder, dated, version-controlled. When the assessor asks, hand them the folder.

What this looks like with CheckoutProof

We built the free scanner to do steps 1–4 in 10 seconds and the audit-evidence export to make step 5 automatic. The free scan gives you the inventory and the SRI/CSP gap analysis as a one-page PDF. The paid product runs the weekly scan, ingests CSP reports, and produces the QSA-ready evidence pack at audit time.

You don’t have to use ours. You do have to do the work somehow. PCI 6.4.3 is the regulatory floor; doing the bare minimum protects your acquirer relationship and, more importantly, protects your customers’ card numbers from ending up on a Magecart skimmer.

Run our free scan on your checkout page right now and see how far you have to go.

Run a free PCI 6.4.3 scan of your checkout page. Get the script inventory and a one-page PDF report. Try it now →