Glossary · Compliance

What is
SAQ-A vs SAQ-D?

Complexity Advanced
Shows up Monthly
Scope Network-native
Operator relevance Context
Share definition X LinkedIn Reddit HN Email
Quick definition

SAQ-A and SAQ-D are two PCI DSS Self-Assessment Questionnaire types. SAQ-A applies to merchants who fully outsource card handling to a compliant third party (hosted checkout only). SAQ-D applies to merchants who touch, transmit, or store cardholder data directly — a far heavier audit.

The short answer

Every card-accepting merchant must complete annual PCI DSS compliance validation. The PCI Council publishes a family of Self-Assessment Questionnaires (SAQs) that vary by how the merchant handles cardholder data. The two extremes are SAQ-A (lightest, for merchants fully outsourcing card handling to a compliant third party) and SAQ-D (heaviest, for merchants who store, process, or transmit card data directly — or who don't fit any other SAQ). Between them sit SAQ-A-EP, SAQ-B, SAQ-B-IP, SAQ-C, SAQ-C-VT, SAQ-P2PE — each narrowing to specific technical configurations. For most multi-brand ecommerce operators, the decision is "stay in SAQ-A" vs. "forced into SAQ-D" — and that choice is driven by checkout architecture.

SAQ-A scope

  • Who qualifies: merchants whose checkout page redirects to a PCI-compliant third party (Stripe Checkout hosted page, PayPal redirect, Authorize.net hosted payment page) or iframes the third party's checkout directly. Card data never touches the merchant's servers.
  • Number of questions: ~22 compliance items.
  • Scope: limited to verifying the third party is PCI DSS validated, and that merchant's website doesn't redirect through an intermediary that could intercept data.
  • Cost to maintain: minimal — annual self-signed attestation + the third party keeps its validation current.

SAQ-D scope

  • Who qualifies: merchants who store PAN in their own systems, transmit it over their own network, or don't fit any narrower SAQ. Custom-built checkout forms that collect card data then tokenize server-side. Also the catch-all for anyone who can't honestly answer yes to SAQ-A's gating questions.
  • Number of questions: ~329 compliance items.
  • Scope: full PCI DSS v4.0 requirements — network segmentation, file integrity monitoring, quarterly ASV scans, penetration tests, documented access control, incident response plan, full encryption audit, logging and monitoring audit.
  • Cost to maintain: $15k–$80k/year for the compliance and quarterly scanning infrastructure. Small operators typically hire a QSA (Qualified Security Assessor) to navigate it.

What operators need to know

  • Checkout architecture determines the SAQ. Stripe Elements (client-side tokenization, card data never touches your server) = SAQ-A-EP or SAQ-A depending on exact configuration. Fully hosted Stripe Checkout = SAQ-A. A custom checkout form that submits card data to your server, even if you immediately tokenize it, pulls you into SAQ-D.
  • Ecommerce platforms vary. Shopify = SAQ-A. WooCommerce with Stripe Elements = SAQ-A-EP. WooCommerce with a plugin that forms card data server-side = SAQ-D (rare these days but possible).
  • iframes can go either way. iframes from a validated PCI-compliant source (Stripe, Braintree) = SAQ-A-EP. iframes built on your own payment form = SAQ-D.
  • Network tokenization does not by itself move you to SAQ-A. You need to fully outsource card data handling to an SAQ-A-qualifying architecture. Tokenization helps scope reduction but doesn't eliminate it.
  • Misclassifying = audit risk. If you attest SAQ-A but your architecture actually requires SAQ-D, and a breach occurs, your merchant agreement is voided and fines apply ($5,000–$500,000). The acquirer can terminate with no notice.

How to stay in SAQ-A as a multi-brand operator

  1. Use hosted checkout or iframe-based card capture on every sub-brand. No custom checkout forms collecting card data server-side.
  2. Vault stored cards via network tokenization or processor tokens — never by storing the PAN yourself.
  3. Keep your PCI scope narrow: don't log card data anywhere in your application logs; don't allow support staff to read PANs in customer service tools (use a redacted "last-4" view only).
  4. Annual SAQ-A attestation + reference to the validated third party's Attestation of Compliance (AoC).

How multiflow handles PCI scope

Checkout integrations across all supported gateways (Stripe, Braintree, Authorize.net, NMI, CyberSource) default to SAQ-A-EP architecture: card capture via validated gateway elements, tokenization on the client side, your servers never see raw PANs. The portal's PCI documentation includes the AoC for every integrated gateway you use, pre-packaged for your annual attestation. See PCI DSS and PCI scope for the full compliance context.

Related glossary terms

Processing across
multiple brands?

multiflow consolidates your ledger, keeps per-brand billing descriptors, and fans out payouts to the right legal entity.

The Operator Briefing

Twice-monthly. No fluff.

Processor shutdowns, reserve-hold playbooks, reconciliation lessons, and the merchant-account decisions that save operators six-figure years. Delivered to your inbox — never spam.

No spam. Unsubscribe in one click.

We use essential cookies · Privacy