WooCommerce gives you what hosted platforms don’t: control of the whole stack. The trade is that PCI DSS looks at the whole stack too. The good news is the split is knowable, most stores can keep their card-data exposure small, and the shortest questionnaire may still be within reach if your gateway is set up the right way.
What WooCommerce’s own documentation says
The official reference is the PCI DSS compliance page in the WooCommerce documentation at woocommerce.com. Four statements there set the whole frame:
- The core plugin is not PCI certified. The docs explain why: WooCommerce itself does not handle cardholder data or process payments directly.
- Your store is in scope anyway. Per the same page, once your site begins accepting card payments, even through a secure hosted gateway such as WooPayments, it falls within the scope of PCI DSS.
- The owner holds the bag. The docs state that PCI DSS compliance is ultimately the responsibility of the store owner, with the payment gateway, the hosting provider, and site administrators each holding a slice of the work.
- WooCommerce doesn’t keep card numbers. The docs state that WooCommerce never stores card details, and that official gateways retain only partial data when using payment tokens, such as the last four digits.
Read those together and the picture is clear. Nobody is certifying your store for you, but nobody needs to panic either: the plugin stays out of the card path, and your job is to keep the rest of your stack out of it too.
Why self-hosting changes the shape of the work
On a hosted platform, the platform runs the website. On WordPress, you do: the hosting account, the TLS certificate, the theme, every plugin, every admin user. So even when a validated gateway collects the card, the website that delivers your checkout page is yours, and PCI DSS cares about anything that can affect the security of the transaction.
WooCommerce’s documentation reflects that reality in its recommendations, which are aimed squarely at the merchant and their host: configure firewalls with your host or network admin, use strong passwords in a secure hosting environment, use SSL on the checkout page, ask your host about malware protection, manage WordPress roles and restrict access to sensitive areas, log and review admin-level activity, use an Approved Scanning Vendor (ASV) if your payment processor requires it, and maintain a PCI DSS policy with periodic risk assessments. Its startup checklist adds: choose a secure, PCI-aware host, never store credit card data on your server or site, and keep WordPress, WooCommerce, plugins, and themes up to date.
None of that is exotic. It’s ordinary operational discipline. The point is that on WooCommerce it’s your discipline, not something a platform attestation quietly did for you.
Find your SAQ free, in about 2 minutes.
Answer a few questions about how you accept cards and the free check computes your likely SAQ type on screen. No email to see it, no card, nothing to install.
How your gateway integration commonly maps to an SAQ
WooCommerce’s docs make one useful distinction: gateways that process payments off-site or through hosted fields (they name Stripe, PayPal, and WooPayments as examples) mean your site is not directly handling raw cardholder data. The docs stop there; they note your payment processor may ask you to complete a Self-Assessment Questionnaire, without mapping which one. The mapping comes from the PCI Security Standards Council’s eligibility rules, and for a WooCommerce store it usually hinges on one question: where does the customer actually type the card number?
- On the processor’s page or inside its iframe. If checkout redirects to the processor, or the card fields are an iframe served by the processor, and all cardholder-data functions sit with validated third parties, that pattern commonly points to SAQ A.
- In a form your pages render. If the card form lives on your own pages and sends card data straight to the processor (a direct-post or JavaScript pattern), your site can affect the security of the transaction even though it never receives card data. That commonly points to SAQ A-EP, which asks considerably more of your website and host than SAQ A does.
- Anywhere your server can see it. If card data passes through or is stored on systems you control, the reduced questionnaires generally fall away and you’re in SAQ D territory.
Same plugin, same theme, three very different workloads. Which is why the gateway configuration screen is quietly one of the most consequential settings in your store. If you’re not certain which pattern your gateway uses, that’s a question worth answering this week, not at renewal time.
The storage override, WordPress edition
The rule that overrides everything: if any system you control stores cardholder data electronically, SAQ D generally applies. WooCommerce’s own checklist says never to store card data on your server or site, and the plugin itself doesn’t. But a WordPress stack has more corners than a hosted platform: a debug log that captured a checkout request, a form or chat plugin that let a customer paste a card number, an order note where staff typed one from a phone call, a database backup with any of the above in it. One stored card number in a corner you forgot rewrites the whole questionnaire. Walk the corners before you claim a reduced SAQ.
How to confirm your SAQ
Your acquiring bank assigns your validation level from your annual card volume and confirms which questionnaire it will accept; a Qualified Security Assessor can make the determination professionally if you want it settled that way. Our free check is the fast first step: it computes your likely SAQ from how you accept cards and shows the result on screen. It’s indicative, not a QSA assessment, and its job is to make sure you don’t spend months closing gaps against the wrong list.
Confirm your SAQ, then close the gaps.
The free check names your likely SAQ on screen in about two minutes. When you’re ready to act on it, the $1,495 PCI DSS v4.0 Readiness & Gap Analysis confirms your SAQ with full rationale, marks every one of the 12 PCI DSS v4.0 requirements covered, partial, or gap, and hands you a prioritized 30/60/90 remediation roadmap. Intake-based, PDF in your inbox within hours, backed by a 7-day pre-delivery money-back guarantee, and the $1,495 credits toward a first month of an Aegis AI subscription at ai4ciso.ai.
Frequently asked questions
Is WooCommerce PCI compliant?
WooCommerce’s official documentation says the core plugin is not PCI certified, because it doesn’t handle cardholder data or process payments directly. The store you build with it is a different matter: the same documentation says that once your site accepts card payments, even through a hosted gateway, it falls within PCI DSS scope.
Who is responsible for PCI compliance on a WooCommerce store?
WooCommerce’s documentation states that PCI DSS compliance is ultimately the responsibility of the store owner. Your payment gateway, your hosting provider, and whoever administers the site each hold a slice of the work, but the accountability, the SAQ, and the signed Attestation of Compliance are the merchant’s.
Which SAQ do WooCommerce stores usually complete?
It depends on how your gateway collects the card. A checkout where the customer pays on the processor’s hosted page, reached by redirect or iframe, commonly points to SAQ A. A card form rendered on your own pages that sends data straight to the processor commonly points to SAQ A-EP. Card data touching your server generally means SAQ D. WooCommerce’s docs don’t map SAQ types; they note your processor may ask you to complete one. Confirm with your acquiring bank or a QSA.
Does WooCommerce store card numbers?
WooCommerce’s documentation states that WooCommerce never stores card details and that its official gateways retain only partial data when using payment tokens, such as the last four digits. What the docs can’t promise is what your own additions do: a logging plugin, an order note, or an export that captures card numbers pulls your store into SAQ D territory.
Do I need ASV vulnerability scans for a WooCommerce store?
WooCommerce’s documentation says to use an Approved Scanning Vendor if your payment processor requires it, and its startup checklist recommends scanning your site regularly with an ASV. Whether scans are mandatory for you depends on your SAQ and your processor’s program, which is exactly what you confirm with your acquiring bank.
Is SSL on my checkout enough to be PCI compliant?
No. WooCommerce’s documentation lists SSL on the checkout page as one item among several: firewall configuration with your host, strong passwords and a secure hosting environment, WordPress role management, admin activity review, malware protection, a PCI DSS policy, and periodic risk assessments. Encryption in transit is necessary, not sufficient.
Related guides
Planning the budget side too? See how much PCI DSS compliance costs, or browse all guides.
This guide is general information, not a QSA assessment, a completed SAQ, an Attestation of Compliance, or legal advice. Platform statements are paraphrased from the official WooCommerce documentation page on PCI DSS compliance (woocommerce.com/document/pci-dss-compliance-and-woocommerce) as of July 2026; check the source for current wording. Confirm your SAQ and obligations with your acquiring bank or a Qualified Security Assessor.