Which PCI SAQ you need depends on how card data moves through your business, not on your industry or size. If every payment is handled by a PCI DSS compliant provider and card data never touches your systems, you are probably on SAQ A (card-not-present) or SAQ P2PE or SAQ SPoC (card-present). If your website influences the payment page without receiving card data, it’s SAQ A-EP. If you use standalone terminals, a virtual terminal or an internet-connected POS, look at B, B-IP, C-VT or C. Everything else is SAQ D for Merchants. A service provider that is allowed to self-assess always uses SAQ D for Service Providers.
Two caveats before you choose. First, your acquirer (the bank behind your merchant account) or the card brands decide whether you can self-assess at all and which SAQ they accept. PCI SSC tells every SAQ filer to confirm with them. Second, many of the top search results for this question are still the PCI SSC’s v3.1 and v3.2.1 instruction PDFs. The current reference is the SAQ Instructions and Guidelines, v4.0.1 revision 1 (April 2025), and PCI SSC warns that merchants “should not assume” an SAQ is the same in v3.2.1 and v4.x. This guide follows the current document. It is general information, not QSA advice.
What are the PCI SAQ types in v4.0.1?
PCI DSS v4.x has nine merchant SAQ types plus one for service providers. SAQ SPoC was added in v4.0. The table summarizes the eligibility criteria in the April 2025 Instructions and Guidelines.
| SAQ | Who it’s for | Channels | Key conditions |
|---|---|---|---|
| A | Card-not-present merchants that fully outsource all account data functions | E-commerce, mail/telephone order | No electronic storage, processing or transmission of card data. For e-commerce, every element of the payment page comes only and directly from a compliant provider, and the site is confirmed not susceptible to script attacks |
| A-EP | E-commerce merchants whose website doesn’t receive card data but affects the payment page or transaction | E-commerce only | Payment processing outsourced except the payment page; elements of the page can come from the merchant’s site |
| B | Imprint machines or standalone dial-out terminals | Card-present, MOTO | Terminals not connected to other systems or the internet; no electronic storage |
| B-IP | Standalone, PCI-listed PTS POI terminals connected by IP | Card-present, MOTO | Terminals isolated from other systems; they don’t rely on another device to connect; secure card readers (SCR/SCRP) excluded |
| C-VT | Manual entry, one transaction at a time, into a third party’s web-based virtual terminal | Card-present, MOTO | Isolated computer in a single location; no card readers attached; no electronic storage |
| C | Payment application (e.g. POS) connected to the internet | Card-present, MOTO | Not connected to other systems; single location; no electronic storage |
| P2PE | Payment terminals in a validated, PCI-listed P2PE solution | Card-present, MOTO | No access to clear-text card data; controls in the P2PE Instruction Manual implemented |
| SPoC | A phone or tablet with a PCI-listed secure card reader (SCRP) in a validated SPoC solution | Attended card-present only | No MOTO, e-commerce or unattended kiosks; payment channel not connected to other systems |
| D for Merchants | Any SAQ-eligible merchant that doesn’t fit the types above | Any | Includes sites that receive card data and anyone storing card data electronically |
| D for Service Providers | Service providers a payment brand allows to self-assess | n/a | The only SAQ for service providers |
None of the merchant SAQs except D apply to service providers. Only A, A-EP and D cover e-commerce.
How do I choose between SAQ A and SAQ A-EP?
This is the most common e-commerce question, and the answer comes down to who controls what the customer’s browser loads on the payment page.
SAQ A applies when every element of the payment page or form comes directly from your PCI DSS compliant provider. PCI SSC gives three examples:
- you have no access to the payment webpage because the provider hosts and manages it entirely,
- your site redirects the customer to the provider’s payment page, or
- your site embeds the provider’s payment page or form in an iframe.
SAQ A-EP applies when any element of the payment page delivered to the browser comes from your website. Examples:
- “direct post,” where your site builds the payment form and the browser sends card data straight to the processor, or
- your site loads or delivers JavaScript that helps create the payment page or controls how card data is sent to the processor.
The difference in workload is large. The Instructions and Guidelines put SAQ A at 14 applicable requirements when the merchant has no access to its webpage, 27 for redirect or iframe setups, and 139 for SAQ A-EP. For A-EP, requirements that mention the “cardholder data environment” apply to your website, because it affects how card data is transmitted even though it never receives it.
There is one more SAQ A condition to know about. Since January 2025, e-commerce merchants must also confirm their site is not susceptible to attacks from scripts that could affect their e-commerce systems. FAQ 1588 says this applies to iframe-style embedded forms, not redirects, and explains the two ways to meet it. Our SAQ A and 6.4.3 explainer covers it in detail.
Which SAQ fits a card-present business?
For in-person payments, start with the equipment:
- Only imprint machines or dial-out terminals over a phone line: SAQ B.
- Standalone terminals connected over IP, approved under PCI PTS POI and isolated from your other systems: SAQ B-IP. If the terminal relies on a computer, phone or tablet to connect, or it is a secure card reader (SCR/SCRP), B-IP doesn’t apply.
- A validated, PCI-listed P2PE solution: SAQ P2PE, provided you follow the provider’s P2PE Instruction Manual. P2PE solutions on PCI SSC’s expired list are no longer considered validated, so ask your acquirer if yours has expired.
- A phone or tablet with a listed secure card reader as part of a validated SPoC solution: SAQ SPoC, for attended card-present transactions only.
- A POS or other payment application connected to the internet, isolated from other systems and in a single store: SAQ C.
- Staff typing card numbers into a provider’s web-based virtual terminal on an isolated computer: SAQ C-VT.
If your environment almost fits one of these but not quite, for example a POS connected to other store systems, the default is SAQ D for Merchants.
When is SAQ D the answer?
PCI SSC lists these examples for SAQ D for Merchants:
- e-commerce merchants that accept card data on their own website,
- merchants that store card data electronically,
- merchants that don’t store card data electronically but don’t meet another SAQ’s criteria, and
- merchants that could meet another SAQ’s criteria but have additional PCI DSS requirements that apply to their environment.
For service providers, FAQ 1578 is explicit: the only correct SAQ for a service provider is SAQ D for Service Providers. It also says a service provider can’t show customers a merchant SAQ or merchant AOC as proof of compliance. That matters for MSPs that manage systems affecting their clients’ payment security; see our post on MSPs and PCI AOCs.
What if I accept payments in more than one way?
Many small merchants have a website, a terminal and an occasional phone order. Each SAQ’s criteria are written for a payment channel, so a mixed setup may not fit a single short SAQ. Ask your acquirer before you start whether it wants one SAQ per channel or a single SAQ D. Their instructions override any general guide, this one included.
Some practical steps before you fill anything in:
- List every way you take a card: website, terminal, phone, email, invoices, mobile reader.
- For each channel, write down the provider and product, for example “hosted checkout, iframe” or “PTS terminal over Wi-Fi.”
- Check whether card data can reach any system you control: a computer, a spreadsheet, an inbox, a call recording.
- Collect each provider’s current PCI DSS AOC. Every SAQ type that outsources processing requires you to confirm your providers are compliant for the services you use.
- Read the eligibility criteria in the actual SAQ, not only a summary. Each criterion is a statement you attest to.
Frequently asked questions
What is the difference between SAQ A and SAQ A-EP?
SAQ A is for merchants whose payment page elements all come directly from a PCI DSS compliant provider, through a hosted page, a redirect or an iframe. SAQ A-EP is for merchants whose own site supplies part of the payment page, such as a direct-post form or JavaScript that builds the form. PCI SSC counts 27 requirements for redirect or iframe SAQ A merchants and 139 for SAQ A-EP.
Can I use SAQ A for phone and mail orders?
Yes, if you meet its criteria. SAQ A covers card-not-present merchants, including mail and telephone order, that fully outsource all account data functions to compliant providers and don’t store, process or transmit card data electronically on their own systems. If staff key phone orders into a virtual terminal, look at SAQ C-VT. If they key them into a P2PE terminal, look at SAQ P2PE.
Which SAQ does a service provider or MSP complete?
Under FAQ 1578, a service provider eligible to self-assess uses SAQ D for Service Providers, the only SAQ for service providers. A merchant SAQ or merchant AOC isn’t enough evidence for its customers. Whether an MSP counts as a service provider for a client depends on what it manages, so confirm with the client’s acquirer or a QSA.
Who decides which SAQ I’m allowed to use?
Your acquirer or the payment brands. PCI SSC writes the SAQs but doesn’t run compliance programs. Its Instructions and Guidelines tell every merchant to contact the organization they submit to, usually the acquirer, to confirm they can self-assess and which questionnaire applies. Larger merchants are often required to complete a Report on Compliance instead.
Are the old v3.2.1 SAQ guides still accurate?
No. PCI SSC warns merchants not to assume an SAQ is the same in v3.2.1 and v4.x. Eligibility criteria were clarified, SAQ SPoC was added, and SAQ A gained requirements, including external vulnerability scans, plus a new script-attack criterion in January 2025. Use the v4.0.1 SAQ and the April 2025 Instructions and Guidelines.
Next step
Want to answer a few questions instead of reading criteria? Try the which PCI SAQ tool. CardSecurity is also building PCI compliance management: SAQ questionnaires, evidence collection and signed packs that MSPs can run across many merchants. It is in early access, not generally available yet. Join the PCI compliance early access.