WooCommerce and PCI DSS 4.0: the checkout script rules

A guide for store owners. Updated October 13, 2026. This explains the rules in plain words; it isn't compliance advice. Your payment provider, or your acquiring bank, decides which questionnaire you file.

Why scripts on the checkout page matter

A card skimmer (often called a Magecart attack) is one extra script on a checkout page that copies the card numbers shoppers type and sends them somewhere else. The page looks the same and orders still go through, so a store can run for weeks without noticing. Skimmers usually get in through a hacked admin account, an outdated plugin, or a third-party script that was itself changed.

PCI DSS, the card industry's security standard, has rules about this. Which ones apply to your store depends on how your card form works.

Which rules apply to you

You redirect shoppers to a payment page hosted by your provider

The shopper leaves your site to pay, and card numbers are typed on the provider's page. You likely file SAQ A, and the PCI Security Standards Council says its script criterion doesn't apply to merchants who redirect (FAQ 1588). A skimmer on your site can still try to send shoppers to a fake payment page, so watching your checkout is still worth it.

Your provider's card form is embedded in your checkout (an iframe)

This is most WooCommerce stores: Stripe's card fields, WooPayments and PayPal's card fields sit in a frame served by the provider, inside your checkout page. You likely file SAQ A. Since the January 2025 version of SAQ A, requirements 6.4.3 and 11.6.1 are no longer in it. Instead, you must confirm that your site "is not susceptible to attacks from scripts". FAQ 1588 gives two ways to do that:

• use techniques that protect the page from scripts, such as (but not limited to) those in requirements 6.4.3 and 11.6.1, run by you or by a third party; or
• get confirmation from your PCI DSS compliant payment provider that its embedded form, set up as it instructs, protects against script attacks.

Your own page takes the card number

If card numbers are typed into fields your page creates, even if a script sends them straight to the processor, you likely file SAQ A-EP or a full assessment. Requirements 6.4.3 and 11.6.1 apply to you, and have been required since March 31, 2025.

What 6.4.3 and 11.6.1 say

6.4.3 covers every script loaded and run in the shopper's browser on the payment page. Each one must be authorized, there must be a way to make sure each one hasn't been changed, and you keep an inventory of them with a written reason each is needed.

11.6.1 asks for a change- and tamper-detection mechanism that alerts you when the payment page's security-relevant HTTP headers or its contents, as the browser receives them, are changed without authorization. It runs at least once every seven days, or as often as your own risk analysis says.

Practical steps for a WooCommerce store

1. Find out which questionnaire you file. Your payment provider's PCI page usually says which SAQ its integration qualifies for.
2. Keep the checkout page lean. Chat widgets, heatmaps, A/B testing and ad pixels rarely need to run on checkout. Every script you remove is one less to inventory and watch.
3. List what runs there. Open your checkout page, then your browser's developer tools (the Network tab, filtered to JS), and write down every script and where it comes from.
4. Get told when something new appears. A Content Security Policy in report-only mode makes shoppers' browsers report scripts from sources you haven't listed, without blocking anything.
5. Close the usual ways in. Keep WordPress and plugins updated, give every admin a strong unique password and two-factor login, and remove plugins you don't use.

How Ropeline Pro helps

Ropeline Pro's store plans include a checkout script watch. It sends a report-only Content Security Policy on the checkout page, so it never blocks anything and can't break checkout. For the first 7 days it learns which script sources your shoppers load. After that, a new source reported by shoppers on 3 different networks is flagged and you get an email; payment providers like Stripe and PayPal are approved from the start.

That gives you an inventory of script sources and alerts when a new one appears. It doesn't check each script's contents against a fingerprint, so on its own it isn't everything 6.4.3 describes, and no tool makes a store compliant by itself.