SAQ A vs SAQ A-EP vs SAQ D: Which One Applies to You?

SAQ A: payment functions fully outsourced

PCI SSC describes SAQ A as covering merchants with account data functions completely outsourced to PCI DSS validated and compliant third parties, where the merchant keeps only paper reports or receipts with account data. SAQ A merchants may be e-commerce or mail and telephone order merchants and do not store, process or transmit account data electronically on their systems or premises. In January 2025, PCI SSC removed requirements 6.4.3 and 11.6.1 on payment page scripts, and the related risk analysis requirement 12.3.1, from SAQ A, and added an eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

The SAQ A script criterion, explained

PCI SSC's FAQ 1588 says the script criterion applies only to e-commerce merchants whose webpage includes a provider's embedded payment page or form, such as an iframe. It does not apply to merchants that redirect customers to the provider (for example with an HTTP 30x redirect, a meta redirect tag or a JavaScript redirect), or that fully outsource payment, for example by emailing customers a link to pay on the provider's site. A merchant can meet the criterion either by using techniques such as those in PCI DSS requirements 6.4.3 and 11.6.1 to protect the page from scripts targeting account data, deployed by the merchant or a third party, or by getting confirmation from its PCI DSS compliant provider that its embedded form, implemented as instructed, includes protection against script attacks. The FAQ adds that a provider of scripts unrelated to payment, which cannot affect the security of card data, is not treated as a third-party service provider for SAQ A.

SAQ A-EP: your website shapes the payment page

The PCI DSS v4.0 SAQ A-EP describes merchants whose website does not itself receive account data but affects the security of the payment transaction or the integrity of the page that accepts card data. Its criteria include: the merchant accepts only e-commerce transactions; all processing of account data except the payment page is outsourced to a PCI DSS compliant provider; the website does not receive account data but controls how customers or their data are redirected to the provider; any provider hosting the website is compliant; and each element of the payment page delivered to the customer's browser comes from either the merchant's website or a compliant provider. PCI SSC's October 2024 bulletin says the v4.0.1 SAQs clarified the eligibility criteria in SAQs A, A-EP and C-VT, so read the current v4.0.1 version in the PCI SSC Document Library before you rely on these criteria.

SAQ D: everything else

The PCI DSS v4.0 SAQ D for Merchants applies to merchants eligible to self-assess that do not meet the criteria for any other SAQ. Its examples include e-commerce merchants that accept cardholder data on their website, merchants that store cardholder data electronically, merchants that do not store card data electronically but do not meet another SAQ's criteria, and merchants whose environment might meet another SAQ's criteria but has additional PCI DSS requirements that apply. PCI SSC's FAQ 1133 notes that SAQ D for Service Providers is the only SAQ for eligible service providers; all other SAQs are for merchants. Other merchant SAQs cover other environments, such as SAQ B-IP, which PCI SSC says is intended only for standalone PCI-approved payment devices not connected to other types of devices in the same network zone, and SAQ SPoC for approved software-based PIN entry solutions on phones or tablets.

How checkout changes move you between SAQs

Your SAQ can change when your checkout does. Illustrative example only: an online shop using its processor's hosted payment page redirects customers away to pay, so the SAQ A script criterion does not apply to that redirect. If it switches to an embedded iframe to keep customers on its site, it still may qualify for SAQ A but must confirm the script criterion. If a developer later builds a card form that posts card numbers to the shop's own server, the shop is accepting cardholder data on its website, one of PCI SSC's examples for SAQ D. Before changing checkout design, ask your provider and acquirer how the change affects your questionnaire. If you take cards through more than one channel, ask your acquirer how to validate each. This is general information, not legal advice (September 17, 2026).