PCI DSS applies to every business that takes card payments, including the one person shop selling handmade candles. What changes with size is not whether the standard applies, but which self assessment questionnaire you fill in, and how much of it you must prove.
For a WooCommerce store the whole question comes down to one design decision: does card data ever touch your server?
SAQ A
You qualify for SAQ A when the card fields are served, and the card data captured, entirely by a validated third party. In practice that means a hosted payment page, or hosted fields loaded from the gateway in an iframe. Your server sees a token, never a card number.
SAQ A is about twenty questions. Most concern your service provider agreements, your written policies and the removal of any stored card data. There is no external vulnerability scanning requirement.
SAQ A-EP
You fall into A-EP when your own page controls the capture, even if the data is posted straight to the gateway. Direct post, an inline form built with the gateway JavaScript API you host yourself, or any setup where your code can read the field values.
A-EP is about 190 questions. It brings quarterly external vulnerability scans by an approved scanning vendor, secure development requirements, penetration testing at least yearly, file integrity monitoring, and change control evidence. For a small store this is not a form to fill in, it is a project with a running cost.
The change in version 4.0 that catches stores out
Two requirements became mandatory for both questionnaires after the March 2025 deadline, and they surprise people because they apply even to SAQ A merchants.
- Script management. You must keep an inventory of every script that runs on the payment page, justify why each one is there, and ensure its integrity. That means knowing what your theme, your analytics, your chat widget and your marketing tags are loading.
- Change and tamper detection. You must detect unauthorised change to the HTTP headers and the content of the payment page, and check at least weekly.
These exist because of digital skimming: an attacker who cannot reach your database at all can still steal cards by injecting a script that overlays the payment field. Hosted fields resist this far better than a self hosted form, which is another argument for staying in SAQ A.
The practical checklist for a WooCommerce store
- Use hosted fields or a hosted page so the card never reaches your server.
- Serve the whole site over TLS 1.2 or better, not only the checkout.
- Never log a card number, and check your error logging and any request capture plugin for the same.
- Keep an inventory of the scripts that run on the checkout, and remove the ones nobody can justify.
- Turn on file change monitoring and review it weekly.
- Use unique accounts for every admin, with multi factor authentication.
- Fill in the questionnaire once a year and send it to your acquirer, or pay the non compliance fee for nothing.
What tokenisation does and does not remove
Storing tokens rather than card numbers takes your database out of scope. It does not take your checkout page out of scope, because that is where the card is entered. This is the distinction people get wrong: a store with a perfectly clean database can still be an A-EP merchant because of how its payment form is built.
Who checks
Your acquirer. Most small merchants are asked to complete the questionnaire through a compliance portal, and are charged a monthly fee if they do not. Above six million transactions a year the requirement escalates to a report on compliance signed by a qualified assessor, but very few WooCommerce stores are near that.
Our security page sets out how the plugin keeps a store inside SAQ A.