PCI DSS v4.0.1 — mandatory since 31 Mar 2025

Do you know every script on your payment page?

PCI DSS Requirements 6.4.3 and 11.6.1 now require merchants to inventory and justify every script on their checkout page, and detect unauthorized changes. If you use Woo/Shopify + Stripe Elements or PayPal in an iframe, the "SAQ A trap" means you must attest your checkout isn't susceptible to script attacks — or you lose SAQ A eligibility. We'll scan your checkout page and show you exactly what's loading, free.

Takes about 15 seconds · no signup required to see your summary

Two requirements, one deadline that already passed

PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Acquirers are already charging non-compliance fees — typically $20–200/month — to merchants who can't show they've addressed them.

Requirement 6.4.3 — script inventory

Every script that loads on a payment page must be inventoried, with a written business justification for why it's there and confirmation of its authorization and integrity.

Requirement 11.6.1 — tamper detection

Merchants must deploy a change- and tamper-detection mechanism that alerts on unauthorized modification of the payment page, at least weekly (or per a defined risk cadence).

The "SAQ A trap": if your checkout is an iframe/embed from Stripe, PayPal or Braintree, you likely qualify for the simpler SAQ A — but only if you can attest your page isn't susceptible to script-based attacks. Many merchants have never actually checked.

What this scan is — and isn't

This free scan gives you a real, useful script inventory for your payment page: every external script, first-party vs third-party, categorized by vendor. It does not assert PCI compliance, and a one-off scan cannot do continuous tamper detection (Requirement 11.6.1) — that needs repeated monitoring over time, which is what the paid tier below is for. Not legal or compliance advice.

Your checkout scripts change — without you touching a thing

A one-time scan is a photo of today. The real problem is what happens after: payment-page scripts change silently, and every change is a new risk you can't see from an old scan.

Vendors update their own scripts

You add a third-party script tag once — but the vendor decides what that URL actually serves, and they change it whenever they push an update. Your code is untouched; what runs on your checkout is now different.

Marketing adds tags through GTM

A new pixel, chat widget or analytics tag gets added via Google Tag Manager — no code deploy, and your developer never sees it. It simply appears on the payment page.

Skimmers swap a trusted script

Card-skimming (Magecart) attacks work by quietly replacing a legitimate third-party script with one that steals card data. It looks identical — only comparing “before vs after” over time catches it.

That's exactly why PCI DSS 11.6.1 asks for change detection at least weekly — not once. A single scan documents your inventory today; ongoing monitoring is what tells you the moment a new or changed script shows up on your checkout.

Weekly monitoring + tamper alerts

We're validating demand for always-on payment-page monitoring before we build it. If you want it, tell us — we'll email you the moment it's ready.

Monitoring

$29/mo

Weekly re-scans of your payment page
Alerts when a new or changed script appears (tamper signal)
Acquirer-ready PDF for your next SAQ A attestation