PCI compliance for ecomm stores: 5 blind spots that can surface later

The nuance tends to live in the gaps between what the onboarding docs cover and what the standard requires. Those can be invisible until a payment processor sends a documentation request, an enterprise buyer asks for a vendor security review, or a QSA starts asking specific questions about checkout page scripts. At that point, a small assumption becomes a project.

Here are five places that nuance tends to surface:

Using Stripe: how much of the compliance burden does it cover?

Stripe is PCI Level 1 certified, which is as high as the certification goes. Using it the right way reduces your compliance burden. But it doesn’t eliminate it.

What Stripe covers is its own processing environment. What it doesn’t cover is the analytics scripts, marketing pixels, and third-party widgets loading on your payment page before the customer clicks Buy. Stripe’s own documentation is explicit: the merchant retains PCI obligations regardless of the payment processor in use.

The SAQ type you qualify for depends on how your integration is built. Redirect integrations may qualify for SAQ A. Stores where any part of the payment page lives on your own infrastructure may require SAQ A-EP or SAQ D, both of which carry significantly more requirements. Where the form lives determines this, not which processor handles it.

Compliance levels: transaction volume sets them, not revenue

PCI compliance levels are set by the card networks, and they’re based on transaction volume. Visa classifies Level 1 merchants as those processing more than 6 million transactions annually. Level 2 covers 1 to 6 million. Levels 3 and 4 cover smaller volumes, with different validation requirements at each tier.

Level 1 requires an annual onsite assessment by a Qualified Security Assessor.
Levels 2 through 4 can self-assess using the appropriate SAQ.
A store doing $8M GMV through 200,000 transactions is almost certainly Level 4. A store doing $3M through subscription billing that clocks several million micro-transactions may land somewhere the team doesn’t expect. Worth confirming before your next renewal cycle.

The annual SAQ: what it covers and what it doesn’t

Your SAQ completion is an annual requirement. The controls underneath it are continuous.

PCI DSS v4.0’s Requirement 12.3.2 introduced a formal targeted risk analysis framework, and the broader shift in v4.0 is from point-in-time audits toward continuous control monitoring. Quarterly external vulnerability scans by an Approved Scanning Vendor are now mandatory in SAQ A.

The annual SAQ documents that the controls were running are supposed to be active year-round, not stood up in January and revisited in December. A store that treats compliance as a once-a-year paperwork exercise is completing the SAQ. It isn’t actually compliant in the way the standard intends.

A PCI-compliant host: where their coverage ends and yours begins

A PCI-compliant host covers the physical environment: servers, network, data center. It doesn’t extend that coverage to your application, your code, or the browser-side behavior of your checkout.

Two requirements that became mandatory in April 2025 sit squarely on the merchant. Requirement 6.4.3 requires an inventory of all scripts on payment pages, confirmation that each is authorized, and verification of their integrity. Requirement 11.6.1 requires a change-and-tamper-detection mechanism to alert when those scripts are modified. Both are merchant obligations. Your host’s certification doesn’t satisfy them.

This is exactly the attack surface that payment page skimming exploits: injected JavaScript on checkout pages that silently captures card data while legitimate processing happens behind it. The infrastructure can be airtight while the payment page is compromised.

Not storing card numbers: a meaningful reduction in scope, with one caveat

Not storing cardholder data reduces your PCI scope. But the standard applies to any entity that “stores, processes, or transmits” cardholder data.

Every time a customer enters their card number at checkout, that data transits through your environment, even if you never write it to a database. The PCI SSC’s guidance on SAQ A eligibility is specific: merchants using embedded payment iframes must confirm their site isn’t susceptible to script attacks, even when they never touch the card data directly.

Not storing cards is a meaningful risk reduction. It’s not a compliance exemption.

None of these are gaps that come from carelessness. They’re what commodity managed hosting and payment processor onboarding teach you by omission.

About the author

[Name] is a [title] at Nexcess, a Specialty Cloud company that builds environments for ecomm merchants who can’t afford to find out what they didn’t know about compliance after the fact. If your store is in that $5–$25M GMV range and you’re not certain which SAQ applies to your current checkout setup, that’s worth a conversation.