What this guide covers
The short answer, and who it applies to
PCI DSS certifies a payment environment, not a CMS, and cares about how the payment page is built and operated, not which software renders it. WooCommerce’s own documentation puts it plainly: “PCI DSS compliance is ultimately the responsibility of the store owner.”
A checkout sits in one of three architectures: a full redirect to the processor’s hosted page, an embedded field on your own page, or self-hosted fields touching the card number directly. Most WooCommerce stores using Stripe Elements, the Stripe Payment Element, or WooPayments sit in the middle case. WooCommerce’s Stripe documentation confirms that “most merchants can use Self-Assessment Questionnaire (SAQ) A for validation,” though the processor or acquirer can still require a different SAQ. PCI DSS is a card brand standard, not a national law, so a UK store and a US store answer the same requirements; only the acquirer relationship and questionnaire differ.
Who operates the checkout day to day is a separate question, and it is what ongoing WordPress security work covers.
Check which payment method your store renders, an embedded field from the processor’s domain or a redirect that sends the shopper off-site, before assuming the questionnaire.
How PCI scope is decided on a WordPress checkout
Where the card number goes, and why that reduces your scope
With an embedded field, the card input is rendered inside an iframe served from the processor’s own domain, though it sits inside your checkout page. Your JavaScript receives a token, not a card number, and your server never stores card details.
The SAQ A e-commerce channel requirement states this directly: “all elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.” Meeting it keeps a merchant on the reduced SAQ A path rather than a longer questionnaire.
Where PCI scope falls in each
Full redirect
Embedded processor field
Self-hosted fields
SAQ labels are typical indications, not guarantees. The acquirer makes the final call on which questionnaire applies, and no NoDrama service is claimed to satisfy any of these requirements.
What changed for SAQ A in 2025
SAQ A now carries an added eligibility criterion: the merchant has to confirm “that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s),” alongside the existing criteria rather than replacing them. The future-dated requirements in PCI DSS v4.x, including this criterion, took effect on 31 March 2025, per the PCI Security Standards Council.
There are two ways to satisfy it: implement 6.4.3 and 11.6.1 yourself, or rely on written confirmation that the processor’s embedded solution already includes those protections, implemented per its instructions. The PCI SSC’s FAQ and the SAQ A form set out both routes. Neither 6.4.3 nor 11.6.1 has published clause text available outside the standard itself, so this guide describes what each asks for rather than quoting it.
Ask your processor, in writing, whether it provides the script-attack confirmation for your integration. A written answer is the artefact worth keeping, not a support chat note.
What requirements 6.4.3 and 11.6.1 ask of the page around the card fields
| What it asks for | What it is watching | What satisfies it in practice | |
|---|---|---|---|
| 6.4.3Script inventory | An inventory of every authorised script on the payment page, a justification for each | What executes in the browser, not the card data itself | A maintained list, and a way to confirm each script’s integrity |
| 11.6.1Change detection | A mechanism that checks the page’s HTTP headers and content against a baseline | Unauthorised changes to the served page, at least weekly or per a targeted risk analysis | A scheduled diff against the baseline, with an alert someone actually reads |
6.4.3, the script inventory
This requirement governs what executes in the browser on the payment page, not the card data. It asks for an inventory of every authorised script, a justification for each, and a way to confirm its integrity. In WordPress terms, every plugin, theme change, or tag manager snippet on the checkout template has to be on a list somebody maintains.
11.6.1, the change and tamper detection
This requirement asks for a mechanism that checks the payment page’s HTTP headers and content against a baseline and alerts someone to unauthorised changes, at least weekly or at the frequency a targeted risk analysis sets. Stated plainly, something has to diff the served page on a schedule, and somebody has to receive the alert.
Why rollback and a CDN are not the same control
Rollback with tested updates answers whether a change broke the page. Tamper detection answers whether an unauthorised script was added at all, between updates. A CDN serves cached assets and filters some injection at the edge, but it does not inventory checkout scripts, and neither control satisfies 6.4.3 or 11.6.1 alone. A record of authorised changes looks closer to the record NoDrama hands over for other maintenance work. That record is not a claim of 6.4.3 or 11.6.1 coverage.
Open your checkout page in a browser, view the network requests, and list every domain a script loads from. That is the starting point of the 6.4.3 inventory.
What good looks like on a WooCommerce checkout
A few markers separate a checkout page that could answer the new SAQ A criterion from one that could not.
What a change record on the payment page contains
- A named list of scripts on the checkout template, with a reason for each and a reviewer for plugin changes.
- A baseline of the page’s headers and content, checked on a schedule, with an alert someone reads.
- A change record: what changed, when, and who approved it.
- Written confirmation from the processor, kept on file, if you rely on that route instead of implementing the requirements yourself.
Backups and off-site copies fit into that record, at how restores and off-site copies are handled.
Pick the last plugin update that touched checkout, then answer from a record rather than memory: what changed, who tested it, and when the page was checked.
What to do about it
- Confirm which payment architecture your checkout uses: a redirect, an embedded field, or self-hosted fields.
- Ask your acquirer or processor which SAQ applies, and get the answer in writing.
- Build the script list for the checkout template from the browser, not the plugin screen.
- Decide what watches the page between releases and who receives the alert.
- Decide who tests a plugin update against that page before it goes live.
Write down the person’s name for each action above. An action with no name is not yet in place.
Rather not own the update testing yourself? NoDrama tests every update on a staging copy first and sends you a dated monthly record. See the three plans and what each one covers.
Not sure what is loading on your checkout page?
Start with NoDrama’s free WordPress audit, no pitch attached.
Common misconceptions
“Stripe is PCI compliant, so my store is.”
The processor’s compliance covers its own iframe and infrastructure. Your plugins and theme stay in your scope.
“A security plugin covers it.”
A general purpose plugin is not, out of the box, a script inventory or change detection mechanism for the checkout template.
“Wix would be safer for PCI than WordPress.”
No primary source compares the platforms on PCI grounds, so this is reasoning from how scope works, not a sourced comparison; scope tracks architecture, not CMS.
“The site runs fine, so nothing has changed on the page.”
Fine decays by default, and a script can be added without anything visibly breaking.
What this does not cover
This guide is written for merchants using an embedded field or a redirect, self-assessing rather than an external audit. It does not cover merchants whose own code renders card fields, a longer questionnaire, or merchants large enough to need external assessment. It does not carry the verbatim text of requirements 6.4.3 or 11.6.1, linked above rather than quoted. And it cannot tell you which questionnaire your acquirer will accept; that is their call, not something a guide can settle.
Where this leaves your payment page
PCI compliance on a WordPress checkout depends on how the payment page is built and whether its scripts are inventoried and watched, not which CMS renders the site. Once you know your architecture and SAQ, the question worth answering is who operates that page between releases.