Every merchant that isn't required to do a full onsite PCI DSS assessment gets to self-assess instead, using one of nine SAQ types. Which one applies comes down to how the merchant actually takes payments, not how big they are or how much volume they run. This article walks through all nine at a high level so you can point a partner in the right direction fast, and it links out to the individual SAQ articles for the full eligibility checklist on each one.

PCI SSC publishes the eligibility rules for each SAQ, but eligibility is self-attested — the merchant (with their acquirer's blessing) is the one confirming they qualify, not PCI SSC and not us. Merchants should always check with their acquirer or payment brand before locking in an SAQ type, since acquirers can layer on additional requirements or have their own final say. Our job as partners is to help them get to the right starting point quickly.

SAQ A — card-not-present merchant (e-commerce or MOTO) that's fully outsourced payment processing to a compliant third party and never touches account data itself, not even electronically.

SAQ A-EP — e-commerce merchant that's outsourced the actual processing, but whose own website still affects the payment page (redirects the customer, loads a script, etc.) even though it never receives card data directly.

SAQ B — merchant using only an imprint machine and/or standalone dial-out (phone line) terminals, with no electronic storage of card data.

SAQ B-IP — same idea as SAQ B, but the standalone terminal connects over IP instead of a phone line, using a PCI-listed PTS POI device.

SAQ C — single-store merchant with a payment application connected to the internet (e.g., POS software), isolated on its own network, no electronic storage.

SAQ C-VT — merchant that manually keys card numbers into a hosted, third-party virtual terminal from an isolated device — no local payment application, no card readers attached.

SAQ D (Merchant) — the catch-all. If a merchant doesn't cleanly fit any of the above (they store card data, they accept it directly on their own site, they've got a more complex environment), they land here. Broadest scope, full PCI DSS requirement set.

SAQ P2PE — merchant using only a validated, PCI-listed point-to-point encryption solution, so there's never any clear-text card data on merchant systems. Works for card-present or MOTO.

SAQ SPoC — new in v4.0. Merchant using a PCI-listed SCRP card reader paired with an everyday phone or tablet as part of a validated SPoC solution. Attended, card-present only — not for MOTO or e-commerce.

Ask the partner three things about the merchant: how do they take cards (in person, over the phone, online), does anything ever touch card data electronically on their own systems, and if it's e-commerce, does any part of the payment page come from the merchant's own site or is it 100% redirected/hosted by someone else. Those three answers eliminate most of the wrong options immediately. For a guided walkthrough, use the interactive SAQ decision tool — it asks these questions in order and points to the right SAQ type along with the eligibility criteria to double check.

The number of PCI DSS requirements a merchant has to work through varies a lot by SAQ — from as few as 3 requirement categories (P2PE) up to the full set (SAQ D). Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) are only required for SAQ types that include Requirement 11: that's SAQ A, A-EP, B-IP, C, and D. SAQ B, C-VT, P2PE, and SPoC don't need them, since those environments don't have an externally-scannable merchant-owned footprint. See the ASV Scanning article for what that process actually involves.

If a merchant's setup is mixed (say, they take e-commerce orders and also run a retail counter) they may need to complete more than one SAQ, one per payment channel. And if their environment has grown more complex since they last assessed, don't assume the same SAQ letter still applies under PCI DSS v4.0 — the eligibility criteria changed for several SAQ types between v3.2.1 and v4.0. When in doubt, SAQ D is always a safe fallback, and their acquirer can confirm.