PCI DSS 6.4.3 and 11.6.1 for WooCommerce: what SAQ A now asks of your checkout page

#What changed on 31 March 2025

PCI DSS 4.0 introduced two requirements aimed at one attack: a script on the payment page quietly copying what shoppers type. It is usually called e-skimming or Magecart. Both requirements were "best practice" until 31 March 2025. Since then they are assessed.

• 6.4.3 asks you to manage every script that loads and runs in the shopper's browser on a payment page. That means a way to confirm each script is authorised, a way to assure its integrity, and an inventory with a written business or technical justification for each one.
• 11.6.1 asks for a change and tamper detection mechanism that alerts someone to unauthorised changes to the payment page's scripts and its security-relevant HTTP headers, as the shopper's browser receives them. It has to run at least weekly, or at another frequency that a targeted risk analysis under requirement 12.3.1 supports.

Most WooCommerce stores do not complete the full standard. They complete SAQ A, the short self-assessment for merchants who outsource card handling. In the January 2025 revision the PCI Security Standards Council took 6.4.3 and 11.6.1 out of SAQ A and put an eligibility criterion in their place: the merchant has confirmed that its site is not susceptible to attacks from scripts that could affect its e-commerce system.

So the two requirements left the form, and the question they answer stayed.

#Does this apply to your store

It depends on how the card details reach your payment provider.

• Redirect. The shopper leaves your site and pays on the provider's own page. The new criterion is not aimed at you. Assessors still commonly expect the page that starts the payment to be looked after.
• Embedded fields. The card fields sit in an iframe served by the provider, inside your checkout page. This is how Stripe, WooPayments, PayPal, Braintree, Adyen and most modern gateways work on WooCommerce. PCI SSC FAQ 1588 applies the criterion to you.
• Your own form. Scripts on your page can touch card data directly. You are on SAQ A-EP or SAQ D, and 6.4.3 and 11.6.1 apply in full.

If you are not sure which one you are, ask your gateway or your acquirer. That answer decides which form you complete, and no plugin can decide it for you.

#Why the iframe does not settle it

The iframe belongs to your provider. The page around it belongs to you. A script injected into your page can draw a fake card form over the real one, or read what the shopper types before the iframe ever sees it. It gets there through a compromised plugin, a hijacked tag manager container, or a third-party script that was changed at its source.

That is why the council's answer for embedded fields is about your page and not the provider's.

#The two routes in FAQ 1588

FAQ 1588 accepts either of two confirmations for a merchant who embeds a provider's payment form:

1. The merchant applies techniques such as those in 6.4.3 and 11.6.1 to its own page.
2. The merchant holds written confirmation from its PCI DSS validated provider that the embedded form includes protection against script attacks, when implemented to the provider's instructions.

Not every provider issues that confirmation, and one that does may attach conditions. Many stores end up on route 1, or hold both. Route 1 is a record you keep yourself: what runs on the page, why it is there, and proof that changes get noticed.

#Build the record with Dragon Checkout Guard

Dragon Checkout Guard is free and keeps everything on your own server. There is no account and no telemetry.

1. Confirm the pages in scope. Open Tools, then Checkout Guard, then Pages. Checkout, Order Pay and Add Payment Method are watched by default. Add Cart or any custom payment path on the Settings tab.
2. Take the first inventory. Press Scan now for a server-side pass over every page. Then use Open & capture on the Checkout page with an item in your cart, so the capture also sees scripts that a tag manager injects at runtime.
3. Authorise what belongs there. Each script gets a justification, an owner, a business purpose, a review date and an integrity method. Recognised providers such as Stripe, PayPal and Google Tag Manager prefill a suggested justification for you to edit.
4. Remove what does not. The most useful outcome of a first inventory is often a chat widget, heat-map or old pixel that has no reason to be on a payment page. Every script you remove is one you never have to justify.

1. Accept the header baselines. The Headers tab records each payment page's Content-Security-Policy, framing and transport headers and flags later drift.
2. Answer the assessment guide. Three plain questions map your integration to the FAQ 1588 route your answers point at, and to the records that route asks for.

#The weekly check

From then on a check runs every week. It rehashes every script, compares each one with what you authorised, and records the outcome whether or not anything changed. A script that changed is flagged for review, and a script whose hash could not be taken says why on its row, so a gap never reads as a clean result. Three Site Health tests tell you when a check is overdue, when a script is unauthorised, and when a header has drifted.

The record of checks that ran matters as much as the alerts. An assessor reading 11.6.1 wants to see that the mechanism ran on schedule, not just that it exists.

#What to hand to an assessor

Three exports sit on the Inventory tab:

• Inventory CSV: one row per script, with its justification, owner, integrity method, current hash and authorisation details.
• Check record CSV: one row per check, with its trigger, the pages covered and what it found.
• Printable integrity record: both of the above, the header baselines and your assessment guide answers, in one document for the browser's print dialog.

Keep copies outside the site. A record that lives only on the server it describes is lost with that server.

#When weekly is not enough

Weekly is the floor. A store with a busy tag manager, several people who can add scripts, or a past incident may decide a week is too long to leave a skimmer running. Moving to a faster cadence is allowed when a targeted risk analysis supports it, and the alert has to reach a named person who will act on it.

Dragon Checkout Guard Pro adds daily, twice-daily and six-hourly checks with a guided risk analysis, alerts by email, signed webhook or Slack, a review queue with reviewer notes, and a tamper-evident ledger behind a printable evidence pack. The companion guide, payment page evidence for an assessor, covers that side.

#What this does not do

Dragon Checkout Guard produces evidence supporting your assessment. It does not certify anything, it does not decide which SAQ you complete, and it does not look inside the provider's iframe, which is covered by the provider's own PCI DSS validation. It detects and records change. It does not block scripts in the browser: that is the job of a Content Security Policy, and the Headers tab will tell you whether yours is still in place.

#Common questions

My gateway says it is PCI validated. Is that enough? It covers the provider's systems and the iframe. It does not cover the page you wrap around the iframe, which is what the SAQ A criterion is about.

Does a Content Security Policy replace this? A good policy limits which origins can run script, and it is worth having. It does not give you an inventory with justifications, and it cannot tell you that an allowed script changed its contents.

Do inline scripts count? Yes. WordPress and WooCommerce print many inline blocks on a checkout page. They are inventoried and fingerprinted, with sensitive values redacted in the stored preview.

Does a full-page cache get in the way? It can. Payment pages should not be cached at all. If yours are, exclude them, so the headers and scripts being checked are the ones shoppers receive.