PCI SAQ-A: The Lightest Compliance Path For Ecom SMBs, And Why You're Probably Not Eligible For It

Every business accepting card payments has to comply with PCI DSS. For the vast majority of ecom SMBs using a fully-outsourced payment processor (Stripe Checkout, Square, PayPal, Shopify Payments), the lightest-weight compliance path is SAQ-A — a 22-question Self-Assessment Questionnaire you complete annually with your acquiring bank.

SAQ-A is the good outcome. What happens if you're not eligible for SAQ-A is worse:

• SAQ-A-EP: 130+ questions. You control some of the payment page (even just analytics on it). Annual ASV scans required.
• SAQ-D: 380+ questions. Card data touches your systems. Annual ASV scans plus often a QSA onsite audit.

The jump from SAQ-A to SAQ-A-EP is ten times the annual work. SAQ-D is twenty to fifty times. And the triggers that bump you out of SAQ-A are subtle.

The PCI SAQ-A tool walks the 14 eligibility questions and tells you which SAQ actually applies to your setup.

What it takes to stay in SAQ-A

1. 100% ecommerce. No card-present swipes (that's SAQ-B territory). No phone orders (SAQ-C-VT). No mail orders.
2. Fully-outsourced payment page. Your checkout redirects to a PCI-compliant processor's hosted form, or embeds their form via an iframe. Examples: Stripe Checkout redirect, PayPal Standard, Shopify Payments on Shopify-hosted checkout.
3. Card data never touches your server. Stripe.js tokenizes in the browser; your server only sees a token. If your server processes the card number even for a millisecond, you're out.
4. No card data storage. Paper, digital, anywhere. Storage bumps you to SAQ-D.
5. No custom JavaScript on the payment page. PCI DSS 4.0 specifically calls out script-integrity on payment pages. Any script you control (analytics, GTM, custom code, chat widgets) takes you out of SAQ-A.

The last one is the gotcha. Every SMB runs Google Analytics or Google Tag Manager. If that script fires on the same page as the payment form (common on Shopify non-hosted checkout, BigCommerce storefront-embedded checkout, WooCommerce with Stripe Elements non-iframed), you're in SAQ-A-EP, not SAQ-A.

PCI DSS 4.0's script-integrity requirement

PCI DSS 4.0 (mandatory from March 31, 2025) adds Requirement 6.4.3, which requires monitoring the integrity of scripts on any page that accepts cardholder data. This applies to SAQ-A-EP and SAQ-D merchants. For SAQ-A merchants using a fully-hosted/iframed payment form, the requirement is lighter but not zero.

What "integrity monitoring" actually looks like: subresource integrity (SRI) hashes on third-party scripts, a tool that alerts on script changes (DataDog, Feroot, Imperva, Jscrambler), or at minimum a weekly manual review of what scripts load on the checkout page.

The common "I thought I was SAQ-A" mistakes

You use Stripe Elements inline. Stripe Elements embedded into your checkout form (not iframed) is technically card data entering your DOM, which moves you into SAQ-A-EP territory. Stripe Checkout (the hosted redirect) stays in SAQ-A. Stripe Payment Element (iframed) stays in SAQ-A.

You have a CSP issue on checkout. If your Content Security Policy allows arbitrary inline scripts on the checkout page, you've failed the script-integrity requirement for SAQ-A-EP automatically.

Your marketing team added GTM to "all pages." Including the payment page. That's custom JS you control on the payment page. SAQ-A-EP.

You collect card data on a phone call and type it into Stripe manually. That's MOTO (mail-order/telephone-order), which is SAQ-C-VT or SAQ-C. Not SAQ-A.

Paper forms with card numbers. Even if you shred them same-day. Paper card data is in scope. SAQ-A doesn't cover it.

The annual SAQ-A workflow

1. Complete the SAQ-A questionnaire (22 questions about the controls you maintain).
2. Pass a PCI quarterly ASV scan (your processor may bundle this — Stripe and Square do).
3. Sign the Attestation of Compliance (AOC).
4. Submit the AOC to your acquiring bank (not to the PCI SSC directly).
5. Repeat every 12 months.

Total effort: 2-4 hours annually if your processor bundles the ASV scan. 4-8 hours if you have to contract with an ASV separately (Trustwave, ControlScan, Sysnet are common).

Merchant levels, briefly

• Level 4: under 20,000 transactions/year. Self-assessed; ASV scan recommended.
• Level 3: 20,000 to 1M ecommerce transactions/year. SAQ + ASV scans.
• Level 2: 1M to 6M transactions/year. SAQ + ASV scans; some card brands require QSA.
• Level 1: over 6M transactions/year. Annual QSA onsite audit + quarterly ASV.

Most SMBs are Level 4 or Level 3. The SAQ-A path applies at any level provided you meet the eligibility criteria.

Related reading

• Merchant Category Code Lookup — adjacent payment-processing optimization
• DNS / Email Auth Audit — adjacent security layer
• Mega Security Analyzer — TLS + headers for the ecommerce site layer

Fact-check notes and sources

• PCI Security Standards Council (PCI SSC) official SAQ-A v4.0 document.
• PCI DSS 4.0 Requirement 6.4.3 on script integrity.
• Stripe's PCI compliance documentation.
• Square's PCI compliance documentation.

This post is informational, not PCI compliance or legal advice. PCI DSS is enforced through the card brands (Visa, Mastercard, Amex, Discover) and your acquiring bank, not through a single regulator. Consult a Qualified Security Assessor (QSA) or your acquiring bank for binding guidance. The eligibility walk in this tool is a self-assessment starting point; official SAQ-A completion requires attestation with your bank. Mentions of Stripe, Square, PayPal, Shopify, WooCommerce, BigCommerce are nominative fair use.