PCI Compliance Basics for Small Online Stores: What Actually Matters

If you run a small online store, PCI DSS compliance probably feels like one of those topics that's either ignored entirely or treated as a tick-box exercise handled by your payment provider. Both approaches get store owners in trouble — the first when a breach happens, the second when their acquirer asks for a Self-Assessment Questionnaire and they realise they don't actually qualify for the easy one.

Here's what PCI compliance actually involves for small merchants, what you can offload to Stripe or Shopify, and where the real obligations sit on your side.

What PCI DSS actually is

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements written by the card brands — Visa, Mastercard, Amex, Discover and JCB — that applies to anyone who stores, processes or transmits cardholder data. It's not a law, but your merchant agreement requires you to comply, and non-compliance can mean fines of $5,000 to $100,000 per month from your acquiring bank, plus liability for fraud.

The current version is PCI DSS v4.0.1, with v3.2.1 retired in March 2024. Most small merchants validate compliance using a Self-Assessment Questionnaire (SAQ).

Merchant levels

• Level 4: Fewer than 20,000 ecommerce transactions per year. This is where most small stores sit.
• Level 3: 20,000 to 1 million ecommerce transactions per year.
• Level 2: 1 to 6 million transactions per year across all channels.
• Level 1: Over 6 million transactions, or any merchant that has had a breach.

Which SAQ applies to your store

This is where small merchants get tripped up. The SAQ you complete depends entirely on how card data flows through your site, not just which processor you use.

SAQ A — the easiest path

Applies if you fully outsource card handling. The customer enters card details on a page hosted entirely by your payment provider (a redirect to Stripe Checkout, PayPal, a hosted Shopify checkout). Your site never touches card data, and the payment form is not served from your domain.

SAQ A-EP — the one people get wrong

Applies if your site uses an iframe or JavaScript element (like Stripe Elements or Stripe.js) where the card field is hosted by the processor but loaded inside your page. Your server doesn't see the card number, but your site controls the page that loads it — meaning a compromised script on your site could skim cards.

This is the Magecart attack vector. SAQ A-EP has roughly 190 questions versus SAQ A's ~30, and PCI DSS v4.0 added specific requirements (6.4.3 and 11.6.1) for script integrity monitoring on payment pages.

SAQ D — full requirements

Applies if you store, process or transmit card data directly. Almost no small merchant should be in this category. If you are, you need a Qualified Security Assessor, not a blog post.

The practical checklist for small ecommerce stores

Assuming you're using Stripe, PayPal, Shopify Payments, Square or similar — here's what you actually need to do:

1. Confirm your SAQ type with your acquirer. Don't guess. Ask them in writing.
2. Use a redirect or hosted checkout if possible. SAQ A is dramatically simpler than SAQ A-EP. If you can live with redirecting to Stripe Checkout instead of embedding Elements, do it.
3. Enforce HTTPS everywhere with HSTS. All payment pages must use TLS 1.2 or higher. TLS 1.0 and 1.1 are explicitly prohibited.
4. Lock down your headers. Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy at minimum.
5. Inventory every script on payment pages. PCI DSS 6.4.3 requires you to maintain a list of all scripts loaded on the payment page, justify why each is there, and ensure their integrity.
6. Monitor for unauthorised changes. Requirement 11.6.1 requires a tamper-detection mechanism on payment pages — Subresource Integrity (SRI) on third-party scripts, or a monitoring tool.
7. Patch everything. Your CMS, plugins, themes, server OS. Unpatched WordPress plugins are the single biggest source of Magecart compromises.
8. Use strong, unique admin passwords with MFA. Requirement 8 of PCI DSS v4.0 mandates MFA for all access to the cardholder data environment, including admin access to your store.
9. Restrict admin access by IP where possible. Especially for staging and admin endpoints.
10. Run quarterly external vulnerability scans if you're SAQ A-EP. Use an Approved Scanning Vendor (ASV). SAQ A merchants are exempt from this specific requirement, but you should still scan regularly.
11. Complete your SAQ annually and submit the Attestation of Compliance to your acquirer.

Where small stores typically fail

Loading analytics or chat widgets on the checkout page

Every third-party script on your payment page is a potential card-skimming vector. Google Tag Manager, Hotjar, Intercom, Facebook Pixel — if they load on the checkout, they're in scope. Either remove them from checkout or accept the SAQ A-EP burden and monitor them properly with SRI hashes.

Missing or weak security headers

A surprising number of stores ship without HSTS, without a CSP, or with a CSP that allows unsafe-inline and unsafe-eval, which defeats the purpose. A strict CSP that whitelists only your payment processor's domains is one of the most effective controls against skimming attacks. Running a free scan with WebSentry will surface missing headers and weak TLS configurations in under a minute.

Cookies without Secure and HttpOnly flags

Session cookies on a checkout flow must have Secure, HttpOnly and SameSite=Lax or Strict set. This is basic but routinely missed on custom-built stores.

Forgetting subdomains

If shop.example.com handles payments but blog.example.com runs an outdated WordPress install with shared cookies or session scope, the blog is in your cardholder data environment whether you like it or not.

Treating PCI as a one-time exercise

Compliance is annual, not lifetime. The SAQ asks you to attest that controls are in place and operating. A checkout that was compliant in January but had a third-party script added in June without review is non-compliant.

A realistic monthly routine

• Review every script loaded on the checkout page. If something new appeared, find out why.
• Check TLS configuration, certificate expiry and security headers — WebSentry grades these automatically and flags regressions if you scan on a schedule.
• Apply CMS, plugin and server patches within 30 days of release (PCI requires critical patches within one month).
• Review admin user accounts and remove anyone who's left.
• Confirm MFA is still enforced on all admin accounts.

PCI compliance for a small store isn't glamorous, but the work is manageable if you understand which SAQ you fall under and treat your payment page as the highest-trust surface on your site. Run a free scan at websentry.dev to see how your store's TLS, headers, CSP and cookies stack up against the PCI DSS technical baseline — it takes about 30 seconds and tells you exactly what needs fixing first.