PCI SAQ types are the different self-assessment questionnaires a merchant can use to report on the Payment Card Industry Data Security Standard (PCI DSS). Each one fits a particular way of taking cards, from a hosted checkout page to a terminal on the counter, and the questionnaire you qualify for decides how many security requirements you have to answer for. Picking the wrong one usually means either answering for controls that do not apply or, worse, skipping ones that do.
Who decides which questionnaire you use
The PCI Security Standards Council (PCI SSC) writes the standard and publishes the questionnaires, but it does not enforce them. In a January 2025 post, the Council states that it “does not define compliance requirements for any organization or set compliance validation responsibilities”. Those rules come from card brands, acquirers and payment facilitators, which the Council calls compliance enforcing entities.
In practice, that means the bank or provider that settles your card payments tells you whether you may self-assess at all and which form it expects. The Council’s SAQ instructions describe SAQs as an alternative for merchants that an acquirer or payment brand does not require to submit a full Report on Compliance, and encourage merchants to contact the organization that will receive the SAQ before starting.
Each SAQ has three parts: eligibility criteria and instructions, the PCI DSS requirements that apply to that environment, and an Attestation of Compliance, the signed declaration that you are eligible and have completed the assessment.
The questionnaires, by how you take payments
The current standard is PCI DSS v4.0.1, which the Council published in June 2024 as a limited revision with no added or deleted requirements. Matching SAQs followed in October 2024. The Council’s SAQ Instructions and Guidelines, available in its document library, summarize the merchant types like this:
| SAQ | Typical merchant setup |
|---|---|
| A | Online or mail/phone-order sales with all card data handling outsourced to a validated third party; no electronic storage, processing or transmission of card data on the merchant’s systems |
| A-EP | Online sales where a validated third party processes the payment, but the merchant’s own website affects the security of the payment page |
| B | Imprint machines or standalone dial-out terminals only, with no electronic card data storage |
| B-IP | Standalone approved PIN terminals with an IP connection to the processor, with no electronic card data storage |
| C-VT | Card details typed one transaction at a time into a third-party virtual terminal on an isolated computer |
| C | Payment application systems connected to the internet, with no electronic card data storage |
| P2PE | Only a validated, PCI-listed point-to-point encryption solution, with no access to clear-text card data |
| SPoC | A phone or tablet with a secure card reader from a validated SPoC solution |
| D | Every merchant eligible to self-assess that does not fit another SAQ, including sites that accept card data directly |
Service providers that may self-assess use only SAQ D for Service Providers.
On SPoC, a note on timing: in a May 1, 2026 bulletin, the Council began a sunset period for the SPoC standard that ends on October 31, 2026. After that it accepts no new SPoC submissions, while existing listed solutions stay valid until their normal expiry.
The online-checkout split: A or A-EP
Most small online shops land on SAQ A or SAQ A-EP, and the difference depends on what your own website sends to the shopper’s browser.
According to the Council’s instructions, SAQ A covers setups where the merchant has no code that captures payment information on its own page. Examples include a payment page hosted entirely by the processor, a redirect to the processor, or an inline frame (iframe) served by the processor.
If any element of the payment page delivered to shoppers comes from the merchant’s website, SAQ A does not apply. A form that your site builds and posts straight to the processor, or a JavaScript file your site loads to create the payment page, points to SAQ A-EP instead. A-EP carries more requirements, because a compromised merchant site could tamper with the payment page even though card numbers never touch the merchant’s servers.
PCI DSS v4.0.1 added requirements 6.4.3 and 11.6.1 to protect payment page scripts, effective March 31, 2025. In its January 2025 update, the Council removed those two requirements, along with the related risk analysis in 12.3.1, from SAQ A. It added an eligibility criterion instead: SAQ A merchants must “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” The Council stressed that the change does not remove the underlying requirements from PCI DSS.
A practical order of work
- Map every way you take cards. List the online checkout, any in-store terminal, phone orders and virtual terminals separately. Each channel can point to a different questionnaire.
- Ask your acquirer or provider what it expects. It sets your validation requirements and the form it will accept.
- Read the eligibility criteria in full. The Council’s instructions say merchants should not assume that the SAQ they used under PCI DSS 3.2.1 still fits under v4.x.
- Collect evidence from your providers. SAQ A and A-EP both depend on third parties that are PCI DSS validated, so keep their attestations on file.
- Sign the Attestation of Compliance last. It is your declaration, not your provider’s.
Security work and fees often get discussed together, but they are separate questions. Our guides to interchange fees and 3D Secure cover what a card payment costs and how online checkouts authenticate the cardholder, and the payment fee calculator compares published processor pricing.
