Knowledge · Ecommerce (WooCommerce)
PCI Compliance for WooCommerce: What’s Actually Required
PCI DSS is the security standard every site that touches card data must follow. The good news for WooCommerce: if you’re using Stripe or Authorize.net’s hosted/tokenized fields correctly, you fall into the easiest compliance category (SAQ A or SAQ A-EP) and your annual paperwork is 30 minutes, not 30 hours. The bad news: most WooCommerce stores configure it wrong and end up in SAQ D territory unknowingly.
№ 01PCI in plain English
PCI DSS (Payment Card Industry Data Security Standard) is the rulebook Visa, MC, Amex, and Discover require any business that accepts card payments to follow. Compliance is self-attested annually via a Self-Assessment Questionnaire (SAQ) — the version depends on how you handle card data.
The SAQ levels relevant to WooCommerce:
- SAQ A: All card data handled by a third party (Stripe Checkout’s hosted page, PayPal redirect). ~22 questions, easiest.
- SAQ A-EP: Card data captured on your site but never touches your server (Stripe Elements, Authorize.net Accept.js). ~191 questions, but most are NA. Realistically 30-60 minutes/year.
- SAQ D: Card data passes through or is stored on your server. ~329 questions, requires vulnerability scanning, formal pen testing. Don’t end up here by accident.
№ 02How to stay in SAQ A-EP
The pattern: card fields render in an iframe served from Stripe or Authorize.net’s domain. The customer types into the iframe; the data goes directly to the processor; you receive a tokenized reference, not the card number. Your server never sees card data.
Implementation in WooCommerce: install the official Stripe plugin (or Stripe’s Stripe for WooCommerce maintained version), enable Stripe Elements (default), do NOT enable ‘Inline credit card form’ (legacy option that bypasses tokenization). Same pattern for Authorize.net: use Authorize.net Accept.js, not the legacy direct-post integration.
Verify by inspecting checkout HTML — card fields should be inside an iframe with src pointing to js.stripe.com or accept.authorize.net. If the fields are native inputs on your domain, you’re in SAQ D territory.
№ 03The infrastructure requirements
Even at SAQ A-EP, you need:
- SSL/TLS everywhere (TLS 1.2 minimum, 1.3 preferred). HTTPS on every page, including the cart and checkout.
- WordPress and plugin updates kept current. Stale plugins are the #1 cause of breaches we’ve helped clean up. Auto-update for security patches; monthly review of major updates.
- Strong admin passwords + 2FA. 2FA on all admin accounts. Discourage shared admin accounts — each user has their own login.
- Quarterly vulnerability scan by an Approved Scanning Vendor (ASV) — required for SAQ A-EP. SecurityMetrics or Trustwave; $300-$800/year.
- Hosting on a PCI-compliant provider (Kinsta, Pressable, WP Engine, Cloudways are all compliant; shared GoDaddy is not).
№ 04Common compliance failures
Three failure patterns we’ve cleaned up:
- Storing card numbers in order notes. Sometimes happens when a CSR pastes a card number from a phone order into the order note ‘for reference’. Instant SAQ D + breach risk. Train the team and audit notes monthly.
- Sending card data via email. “Just email me your card number for the phone order” — never. Use Stripe’s phone-payment workflow or send a pay-by-link.
- Plugin abandonment. Plugin developer stops updating; security patch never comes; vulnerability gets exploited. Audit plugins every 6 months; replace abandoned ones promptly.
№ 05The annual paperwork in practice
For a typical SAQ A-EP mid-market WooCommerce store:
- Schedule quarterly ASV scan (auto-runs once configured).
- Once per year, complete the SAQ A-EP form — most questions answer themselves once Stripe Elements is the integration. 30-60 minutes.
- Sign the Attestation of Compliance (AOC). Some merchant accounts request this annually; many don’t actively collect it but require you to attest.
- Keep records: SAQ, AOC, scan results. 3-year retention recommended.
Total annual time: 2-4 hours plus scan cost. Manageable. Compare to SAQ D’s 20-40 hours plus mandatory pen testing — the configuration choice at build time is the biggest compliance lever you have.
⚠What to avoid
- Using a third-party plugin to ‘simplify’ checkout that captures card fields directly on your domain. Even if it ‘sends data securely’ to Stripe, the card data touched your server. You’re in SAQ D.
- Skipping the quarterly ASV scan because ‘nothing has changed.’ Scan is required. Failed scans are 60-day-grace; missed scans are non-compliant.
- Treating PCI as one-time paperwork. Plugin updates, hosting changes, integration changes — all can move you between SAQ levels. Review compliance after any major change.
Related questions
Go deeper
Three Ways to Start · No Sales Pitch
Want this analyzed on your site?
$500 audit. 5-day delivery. Refundable on engagement.