Since 31 March 2025, two PCI DSS requirements have applied to the page your customers type their card into. 6.4.3 asks you to keep an inventory of every script loaded on that page, with a written reason why each one is needed. 11.6.1 asks you to detect unauthorised change to it, and to check at least weekly. Neither is about your server. Both are about the page in the browser.

It audits the right page

Your payment page is usually not /checkout. Most gateways move the payment step to WooCommerce's order-pay page, and that is where the provider's script actually loads. A policy or a monitor pointed at the checkout page protects nothing. This plugin follows the real pay URL for an order you name, so it reads the page the card is typed into.

It reads what the page served, not what WordPress registered

The page is fetched over HTTP exactly as a browser would fetch it, and the scripts are taken from the response. The enqueue registry is deliberately ignored, because PCI cares about what the browser loads — including anything a theme, another plugin or a tag manager injects late. Inline scripts are inventoried too.

Every script gets a name

Each one is attributed to WordPress core, a named plugin, a named theme, your own site or a third-party host. That owner column is the useful part: a tag manager on the payment page is a third party with permission to run code next to a card number. It may be perfectly justified — but 6.4.3 wants the justification written down, and writing it down is often when you decide it did not need to be there.

A baseline, then a weekly check

wp ap-pci baseline records the current scripts as the set you approved, with a note of who approved them. That file is your evidence. wp ap-pci check compares the live page against it and lists what is new, changed or gone. It exits non-zero when anything changed, so one cron line is the whole 11.6.1 mechanism:

0 3 * * 1 cd /path/to/site && wp ap-pci check || mail -s "Payment page changed" you@example.com

Quiet unless something really changed

A weekly check is only useful if it stays silent when nothing happened. A real payment page carries per-request values inside its inline scripts — WooCommerce alone emits a nonce timestamp and a cart JWT that differ on every single request. Inline scripts are therefore identified by the id WordPress gives them, and those changing values are masked before hashing. Tested on a page with 91 scripts: repeated checks report nothing, while an edited script file and a newly injected third-party script are both caught.

Honest about hashes

Scripts on your own server are hashed from disk, so any edit is caught. Third-party scripts are hashed only when you ask, because provider CDN scripts are often unversioned and change without notice — hashing them by default would make every check noisy and you would stop reading the mail. Added and removed third-party scripts are always reported either way.

Good to know

WP-CLI only: there is no admin screen, and nothing is added to your site's front end. You need an unpaid order to open a payment page with, because the page only renders while an order is unpaid. Run it once per payment method — each produces a different page. This plugin reports; it does not block scripts, add a Content-Security-Policy or remove anything. AllPlugin is not a QSA and this plugin is not an attestation: your acquirer decides which questionnaire applies to you.