TL;DR Summary
There are multiple PCI Self-Assessment Questionnaire (SAQ) types that your merchants must choose from to accurately describe their exposure to sensitive cardholder data and risk.
As a payment provider, it’s critical that your merchants understand and select the correct SAQ type.
Merchants should run data flow mapping exercises before committing to a specific SAQ type.
Payment providers can leverage a strategic white-labeled PCI partner to streamline this process.
A quick look at any online merchant forum reveals a clear pain point: confusion over SAQ types and workflows. While it can seem straightforward, many merchants struggle with the technical compliance language and requirements for each level.
This article summarizes key details to help your merchants better understand their current PCI SAQ requirements and streamline the process.
What a PCI SAQ Covers and Who Completes One
The PCI Self-Assessment Questionnaire is a validation tool merchants use to attest to PCI DSS compliance instead of a full Report on Compliance (ROC). The correct SAQ depends on how card data flows through a merchant's systems, because it measures exposure to sensitive cardholder data and risk.
But who needs to complete a SAQ?
Merchant validation requirements are generally influenced by annual transaction volume, card brand rules, acquirer requirements, and risk profile. Level 1 merchants often complete a Report on Compliance, while many lower-volume merchants validate through an SAQ. However, acquirers and payment brands can require different validation methods based on the merchant’s environment, transaction volume, or assessed risk.
Now that we’ve covered who may need to validate PCI DSS compliance, we can dive into the different SAQ types.
SAQ Type |
Typical Merchant Environment |
|---|---|
SAQ A |
Merchants Who Fully Outsource Card Data Handling |
SAQ A-EP |
Merchants With a Role in the Payment Page |
SAQ B and SAQ B-IP |
Standalone Terminal Merchants |
SAQ C and SAQ C-VT |
Connected Systems and Virtual Terminals |
SAQ D |
The Comprehensive Questionnaire for Complex Environments |
SAQ P2PE |
Merchants using a validated, PCI SSC-listed point-to-point encryption (P2PE) solution |
SAQ SPoC |
Merchants using PIN entry apps on standard commercial off-the-shelf mobile devices paired with a secure card reader |
SAQ CP |
Merchants accepting contactless tap payments on COTS devices |
SAQ A: Merchants Who Fully Outsource Card Data Handling
This is the least burdensome SAQ, reflecting minimal PCI scope.
SAQ A applies to e-commerce and mail order/telephone order (MOTO) merchants that fully outsource all cardholder data functions to PCI DSS validated third parties. In short: These merchants do not hold any card data on their own systems, network, or premises.
For e-commerce, this typically means using a redirect or iframe checkout where the payment page is hosted entirely by the third-party processor, so the merchant's systems never touch, transmit, or store card data. MOTO merchants qualify similarly when all card data capture and processing happens through a validated third-party service.
SAQ A merchants keep card data off their own systems entirely, aside from paper records like printed receipts.
Consider this example: An online furniture store adds a "Checkout" button that redirects the customer away from the merchant's own website to a hosted payment page operated entirely by a processor like Stripe, PayPal, or Authorize.net. The customer enters their card number directly on that third-party page, the processor handles authorization, and only a transaction confirmation is passed back to the merchant's site.
An embedded iframe checkout works the same way in principle. The card entry fields are served from the processor's domain and rendered inside a frame on the merchant's page, so keystrokes never pass through the merchant's own servers, even though the customer feels like they never left the site.
In both cases, the merchant's systems only see an order ID and approval status, never the primary account number, expiration date, or CVV. This approach keeps them within SAQ A scope.
SAQ A-EP: Merchants With a Role in the Payment Page
SAQ A-EP applies to e-commerce merchants who outsource actual payment processing to a validated third party but still host or control the web page where the customer enters their card details.
Card data never touches the merchant's servers, but the merchant's systems influence how that data is collected and transmitted, exposing the merchant to risk. A compromised or tampered payment page can skim card data at the point of entry, even if it's forwarded straight to the processor.
This control point is why SAQ A-EP carries far more requirements than SAQ A. It has closer to 140 questions versus roughly 20, covering areas like network segmentation, vulnerability management, and page-script integrity.
Common setups landing merchants here include direct-post integrations, where the merchant's page submits card fields via an API call to the processor, and certain iframe implementations where the merchant controls the surrounding page even though the frame itself is hosted elsewhere.
SAQ B and SAQ B-IP: Standalone Terminal Merchants
SAQ B applies to merchants, like brick-and-mortar stores, using standalone imprint machines or dial-out terminals with no connection to other systems and no electronic cardholder data storage. The terminal dials directly to the processor over a phone line, and the merchant's network is never involved.
SAQ B-IP covers the same standalone, dedicated payment terminal, but the terminal connects to the payment processor over an IP network instead of a phone line. Because that connection touches the internet, B-IP carries additional requirements around securing the terminal's network connection that don't apply to the phone-based SAQ B.
Both share the same core eligibility requirement. The terminal must be a standalone, PCI-listed device that is not connected to any other systems within the merchant's environment, and the merchant must never store, process, or transmit cardholder data electronically outside that terminal. Essentially, no card data touches the merchant's POS systems, computers, or network.
SAQ C and SAQ C-VT: Connected Systems and Virtual Terminals
SAQ C applies to merchants whose payment application system, typically point-of-sale software or a similar payment application, is connected to the internet, but the system itself does not electronically store cardholder data. Because the environment is network-connected, the merchant carries meaningfully more risk than a fully isolated SAQ B setup. The payment application, the underlying systems it runs on, and any network segment it touches are all in scope.
SAQ C-VT applies to merchants who manually key card details into a browser-based virtual terminal hosted by a third-party processor, using a device that is isolated from other systems in the merchant's environment. Typically, this device is only a virtual terminal with no other applications or card data storage. Card data is entered manually and transmitted directly to the processor, with nothing retained locally.
Both of these SAQ types require added security controls appropriate to an internet-connected environment. It’s critical to configure firewalls to protect the payment system or virtual terminal device, enforce strict access management to limit who can reach the system, use unique user credentials, and follow secure maintenance practices to keep the connected environment from becoming an entry point for attackers.
SAQ D: The Comprehensive Questionnaire for Complex Environments
SAQ D is the catch-all category: it applies to any merchant or service provider that stores, processes, or transmits cardholder data in a way that doesn't fit the narrower profile of any other SAQ type.
This type includes merchants running e-commerce platforms that touch card data directly, POS systems that store data, or any environment with card data outside a fully outsourced or isolated setup.
Because SAQ D covers entities with the broadest possible exposure, it requires a full assessment against all applicable PCI DSS requirements, all twelve categories, not a subset. That means a thorough review of network segmentation and firewall configuration, encryption of stored and transmitted card data, access control and authentication, logging and monitoring, vulnerability management, and incident response, essentially the same scope a QSA would evaluate in a full ROC, just self-assessed.
Notably, any service provider eligible to self-assess completes SAQ D regardless of what a merchant using that provider's services might qualify for on the merchant side.
P2PE and Other SAQ Types to Recognize
SAQ P2PE applies to merchants using a validated, PCI SSC-listed point-to-point encryption (P2PE) solution, where cardholder data is encrypted at the point of interaction the moment the card is swiped, dipped, or tapped.
The encryption keys are held by the P2PE solution provider, not the merchant, so even if the merchant's network were compromised, no usable card data would be exposed.
Because the merchant never has access to clear-text card data, SAQ P2PE cuts the assessment down to a short list of questions. Merchants must confirm that the P2PE solution is properly implemented and listed, that the hardware hasn't been tampered with, and that basic organizational controls are in place. It's a significant scope reduction compared to SAQ C or D.
It’s also important to be aware of two newer, less common SAQ types an acquirer might reference:
SAQ Software-based PIN Entry on COTS (SPoC), for merchants using PIN entry apps on standard commercial off-the-shelf (COTS) mobile devices paired with a secure card reader.
SAQ Contactless Payments on COTS (CP), for merchants accepting contactless tap payments on COTS devices. Both are narrower profiles built for newer mobile acceptance models.
Matching Your Merchants to the Right SAQ
The process can be easier than your merchants think. Two questions eliminate most of the field fast:
Is the entity a service provider or a merchant? Service providers eligible for self-assessment land on SAQ D by default. Settling this first prevents a service provider from wasting time evaluating SAQ A or SAQ C-VT eligibility that was never on the table.
Does cardholder data touch the entity's own systems or network in any form? If card data is fully outsourced to a validated third party with no exposure to the merchant's environment, that points toward SAQ A or A-EP. If it touches an internet-connected system even without being stored, that's SAQ C or C-VT territory. If it's stored, processed, or transmitted more broadly, SAQ D is likely the answer.
To make this process clearer, merchants can trace:
Where card data enters their environment
What systems or applications touch it
Whether it's stored anywhere
How it's transmitted onward
This exercise often reveals integration details, like an iframe the merchant assumes was "hosted" but actually sits on their own page, which changes eligibility.
Because misclassifying eligibility can mean a failed validation or missed scope, merchants should confirm their SAQ selection with their acquiring bank, the relevant payment brand, or a Qualified Security Assessor before submitting.
How to Streamline Merchant SAQs
The rules seem simple, but once merchants are in the documentation, it’s easy to get confused. Working with a white-labeled PCI partner can help payment providers reduce merchant confusion, improve support efficiency, and give teams better visibility across the portfolio.
How does this work? Consider the core features of Aperia Compliance’s PCI Apply:
Guided SAQ workflows help merchants navigate the questions that apply to their environment with clearer direction.
Automated merchant communications keep merchants informed with branded communications, reminders, and program messaging.
Portfolio-level reporting tracks merchant progress, scan status, validation activity, and overall compliance trends.
Our program is white-labeled, so merchants see your branding throughout the PCI experience. That helps payment providers deliver a clearer, more supported compliance journey without sending merchants into a disconnected third-party experience. Contact our team today to learn how Aperia Compliance can support both your merchants and your growth goals.
What is the PCI DSS Self-Assessment Questionnaire? What is the difference between SAQ A and SAQ A-EP? Do small merchants in your portfolio still need to validate PCI DSS compliance?How often do merchants need to complete a PCI SAQ? Who is required to complete SAQ D? How can payment providers make SAQ selection easier for merchants?
FAQ
A PCI DSS Self-Assessment Questionnaire, or SAQ, is a validation tool that eligible merchants and service providers use to assess and attest to the PCI DSS requirements that apply to their specific payment environment. For payment providers, the SAQ is important because the correct questionnaire depends on how each merchant accepts payments and how cardholder data flows through their environment.
Different SAQ types exist because not every merchant handles cardholder data the same way. A merchant using a fully outsourced hosted payment page may have a much smaller validation scope than a merchant whose systems store, process, or transmit cardholder data. Helping merchants understand the right SAQ type can reduce confusion, limit rework, and create a clearer validation experience.
SAQ A generally applies when all account data functions are fully outsourced and all payment page elements are delivered directly by PCI DSS compliant third-party service providers, such as through a redirect or eligible hosted iframe implementation.
SAQ A-EP applies when the merchant outsources payment processing but its website or payment page can still affect how card data is collected or transmitted, such as with certain direct-post or merchant-controlled payment page implementations.
In most cases, yes. Merchants that accept payment cards are expected to validate PCI DSS compliance according to requirements set by their acquirer or payment brand. For many small merchants, that validation is completed through an SAQ rather than a full Report on Compliance.
Merchants complete an SAQ annually, alongside quarterly ASV scans if their SAQ type requires them, such as SAQ A-EP, C, or D. The exact validation requirements, deadlines, and supporting documentation are usually determined by the acquirer, payment brand, or other compliance-accepting entity.
SAQ D applies to merchants that store, process, or transmit cardholder data in a way that does not qualify for a narrower SAQ type. Service providers that are eligible to self-assess generally use SAQ D for Service Providers, but validation requirements should be confirmed with the relevant payment brand, acquirer, or compliance-accepting entity.
Payment providers can make SAQ selection easier by helping merchants understand how they accept payments, where cardholder data enters their environment, which systems touch it, and whether any data is stored, processed, or transmitted. Guided workflows, integrated ASV scanning, branded communications, and portfolio-level reporting can help create a clearer merchant experience.