PCI DSS 6.4.3 and 11.6.1 for WooCommerce: Payment Page Scripts

PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 have applied since 31 March 2025. They ask merchants to keep an inventory of every script on their payment pages with a written reason for each, confirm each is authorized and intact, and get alerts when scripts or security headers change. Most WooCommerce stores that use embedded card fields from Stripe, WooPayments or PayPal validate with SAQ A, where these became an eligibility check in January 2025. This guide explains what applies, how to meet it, and where a plugin helps. It is general information; your acquirer or QSA has the final say.

Why do payment page scripts matter?#

E-skimming (often called Magecart) adds or changes a script on a checkout page so it copies what shoppers type. Even when card fields are inside a provider's iframe, a malicious script on the parent page can, for example, swap the iframe for a fake form. PCI SSC published an information supplement on this, "Payment Page Security and Preventing E-Skimming", on 10 March 2025, saying the requirements "focus on ensuring that payment page scripts are properly authorized, checked for integrity, and monitored for tampering" (PCI SSC blog (opens in a new tab)).

What do 6.4.3 and 11.6.1 say?#

In summary (read the exact wording in the PCI DSS v4.0.1 standard from the PCI SSC document library; the library requires accepting a licence, so we summarise here):

PCI SSC's 30 January 2025 post confirms that 6.4.3, 11.6.1 and 12.3.1 "become effective as of 31 March 2025" (source (opens in a new tab)).

What changed for SAQ A in January 2025?#

The same post announced a revised SAQ A that:

• removed requirements 6.4.3, 11.6.1 and 12.3.1 from the questionnaire, and
• added an eligibility criterion that the merchant "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

PCI SSC added that the change does "not remove or diminish the underlying requirements within PCI DSS." The October 2024 SAQ A version was retired on 31 March 2025.

Which WooCommerce stores does FAQ 1588 cover?#

FAQ 1588 (opens in a new tab) (February 2025) says the script criterion applies to e-commerce merchants "with a webpage that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frame(s) (iframes))". It does not apply to stores that redirect shoppers to the provider's own page, or that fully outsource payments.

How do I meet it?#

FAQ 1588 gives two routes:

1. Use techniques such as those in 6.4.3 and 11.6.1 to protect the page from scripts targeting account data. "These techniques may be deployed by the merchant or a third party."
2. Get confirmation from your PCI DSS compliant payment provider that its embedded form, used as instructed, includes techniques that protect your payment page from script attacks.

Route 2 can be the least work: ask Stripe, WooPayments or PayPal whether they provide that written confirmation for your integration. Route 1 is a process you run yourself.

What does a practical process look like in WooCommerce?#

1. List every script on the checkout and pay for order pages. Include theme and plugin files, the gateway's SDK, analytics and tag managers, and inline scripts. Check what the browser loads, not only what WordPress enqueues, because tag managers add scripts later.
2. Write down why each one is needed and who approved it. Remove what you cannot justify. Analytics rarely needs to run on the payment page.
3. Record integrity. Hash files you control. For provider SDKs that change on their own schedule, such as js.stripe.com/v3, record the address and rely on the provider.
4. Watch for change at least weekly. Re-hash scripts, record the security headers your checkout sends (Content-Security-Policy, X-Frame-Options and similar), and alert someone when anything new or changed appears.
5. Consider a report-only Content Security Policy listing the script origins you authorized, so browsers report anything else.
6. Keep the evidence: the inventory, justifications, change log and alerts.

What can a plugin not do?#

Be clear about the limits before relying on a tool:

• No plugin makes a store compliant. Compliance is assessed by your acquirer or a QSA, not by a tool.
• A plugin on your site cannot see inside the provider's iframe. That part is the provider's responsibility.
• Browser-side reporting only covers browsers that run it; server-side checks see what your server sees, which can differ from what a targeted shopper receives.

How ChargeWarden helps#

ChargeWarden inventories scripts on WooCommerce payment pages from three places (what WordPress prints, what shoppers' browsers load, and a daily scan), asks you to authorize each one with a written justification, hashes content, checks security headers, emails you about new or changed scripts, and exports a CSV of the evidence. It states what it does not cover on the screen and in every export. See Payment page scripts.

Sources#

Checked October 24, 2026.

• PCI SSC blog: Important updates announced for merchants validating to SAQ A (opens in a new tab) (30 January 2025)
• PCI SSC FAQ 1588 (opens in a new tab) (February 2025)
• PCI SSC blog: FAQ clarifies new SAQ A eligibility criteria (opens in a new tab) (28 February 2025)
• PCI SSC blog: Payment Page Security and Preventing E-Skimming (opens in a new tab) (10 March 2025)

This guide is general information, not a PCI DSS assessment or legal advice.