Shopping cart PCI compliance guide for Magento 2 and WooCommerce.

PCI DSS is the card industry’s security standard. If your store takes card payments, it applies to you — but for most small and mid-size stores it is far less work than the acronyms suggest, provided you make one decision correctly. This guide is the plain-language version.

The one decision that matters: don’t touch card numbers

Your compliance burden is decided by whether card data ever passes through your own server. If the card form is delivered by your payment processor — a hosted payment page, or hosted fields embedded in your checkout — the card number goes straight from the customer’s browser to the processor and your site never sees it. You then qualify for the simplest self-assessment (SAQ A), which is a short questionnaire, not an audit.

Every mainstream gateway supports this today: Stripe Elements, Braintree hosted fields, Authorize.net Accept.js, PayPal, Square. On Magento 2 and WooCommerce the official gateway extensions all use them. If your store has a custom or old payment module that posts the card number to your own server first, replacing it is the single most valuable security change you can make.

Merchant levels and what they require

• Level 1 — over 6 million card transactions a year. Annual on-site assessment by a Qualified Security Assessor and quarterly scans by an Approved Scanning Vendor.
• Level 2 — 1 to 6 million transactions. Annual self-assessment questionnaire and quarterly ASV scans.
• Level 3 — 20,000 to 1 million e-commerce transactions. Annual SAQ and quarterly ASV scans.
• Level 4 — under 20,000 e-commerce transactions. Annual SAQ; scans as your acquirer requires.

Which SAQ you fill in depends on how you take payments, not on your level. Fully hosted or hosted-fields checkout: SAQ A. A checkout page you control that collects card data and sends it on: SAQ A-EP, which adds quarterly external scans. Storing or processing card data on your own systems: SAQ D, the full standard — avoid it unless you have a real reason.

The 12 requirements, in normal language

Build and maintain a secure network

1. Firewall. Your host handles the server side; on your end, a web application firewall (Cloudflare or your host’s) in front of the store, and a firewall on the office network. 2. No vendor defaults. Change every default password — the router, the admin account named admin, the database user that shipped with the install.

Protect cardholder data

3. Protect stored data. The best protection is not storing it. Never store the CVV under any circumstances. For recurring billing or saved cards, use your processor’s vault and keep only the token they give you. 4. Encrypt in transit. HTTPS on the whole site, not just checkout, with current TLS. Never access the admin over public Wi-Fi without a VPN.

Maintain a vulnerability management program

5. Malware protection. Anti-malware on every office computer that touches the store, and a server-side scanner (Wordfence, Magento Security Scan, or your host’s). 6. Secure systems. Keep Magento or WordPress core, the theme and every extension updated; a store running last year’s plugin versions is the most common way we see stores breached. Remove extensions you do not use.

Implement strong access control

7. Need-to-know access. Staff who edit products should not be able to see orders’ payment details. Both Magento 2 and WooCommerce support admin roles — use them. 8. Unique IDs. One login per person, never shared, with two-factor authentication on the admin. 9. Physical access. Lock the office machines and the server room, if you have one.

Monitor and test

10. Logging. Keep admin action logs and server logs, and actually look at failed-login patterns. 11. Test regularly. If your SAQ requires it, quarterly scans by an Approved Scanning Vendor — expect $80–$250 a year; anything much more is buying a badge, not security. Your first scan will almost certainly flag server settings your host has to fix; allow one to four weeks.

Maintain a policy

12. Written security policy. A short document saying who has access to what, how updates are applied, and what happens when someone leaves. For a small store this is two pages, and it is what your acquirer asks for first after an incident.

Practical checklist for your store

1. Use a hosted or hosted-fields payment form so card numbers never reach your server. Confirm it by reading the gateway extension’s documentation, not the sales page.
2. Never store the CVV. Never store full card numbers; use the processor’s vault and tokens for saved cards and recurring billing.
3. HTTPS everywhere, and admin access with two-factor authentication.
4. Update core, theme and extensions on a schedule, and remove what you do not use.
5. Separate admin roles: products and content staff cannot see payment data.
6. Put a web application firewall in front of the site and run a malware scanner on it.
7. Complete the SAQ your payment setup calls for, and if it requires ASV scans, schedule them quarterly.