Internationally recognized certification body ensuring compliance, quality, and global market access for your business.
Contact For Services
Join thousands of professionals who have upgraded their skills through our certified training programs globally.
Explore Training Calendar
Choosing the correct PCI DSS Self-Assessment Questionnaire (SAQ) is an important step for e-commerce businesses that outsource payment processing to third-party service providers. Two commonly considered options are SAQ A and SAQ A-EP. Although both questionnaires are designed for specific merchant environments where payment processing is outsourced, they have different eligibility criteria, security responsibilities, and assessment requirements. Understanding PCI DSS SAQ A vs SAQ A-EP helps merchants select the appropriate validation route based on how their payment pages operate and how their websites interact with payment transactions.
SAQ A generally applies to eligible card-not-present merchants that have fully outsourced their account-data functions to PCI DSS-compliant third-party service providers. SAQ A-EP is intended for eligible e-commerce merchants whose websites do not receive account data but can affect the security of the payment transaction or the integrity of the payment page. The distinction is particularly important for redirect-based payment flows, embedded payment forms, and merchant-controlled payment pages.
This guide compares SAQ A and SAQ A-EP using PCI DSS v4.0.1 guidance, practical implementation scenarios, eligibility criteria, evidence expectations, and a decision table. It also explains why selecting a shorter questionnaire does not automatically establish compliance and why merchants should confirm their validation requirements with the organization responsible for accepting their compliance documentation.
A PCI DSS Self-Assessment Questionnaire is a validation tool designed to help eligible merchants and certain service providers assess and report their compliance with applicable PCI DSS requirements. Each SAQ is intended for a particular type of payment environment. It contains questions corresponding to requirements relevant to that environment and includes instructions for documenting assessment results.
The Payment Card Industry Data Security Standard (PCI DSS) is maintained by the PCI Security Standards Council (PCI SSC). Its requirements are designed to protect payment account data and support secure payment environments. The applicable SAQ depends on how an organization accepts payments, where account data is handled, which systems can affect payment security, and whether the organization meets every eligibility condition for the selected questionnaire.
SAQs are not interchangeable forms that merchants can select based only on convenience. A merchant must satisfy the complete eligibility criteria for the relevant questionnaire. If the actual payment environment falls outside those criteria, the merchant may need a different validation approach, potentially including SAQ D or a Report on Compliance (ROC), depending on the requirements of its acquiring bank, payment brand, or other compliance-accepting entity.
PCI DSS SAQ A is designed for eligible card-not-present merchants, including e-commerce and mail-order/telephone-order (MOTO) merchants, that have completely outsourced their account-data processing functions to PCI DSS-compliant third-party service providers. These merchants do not electronically store, process, or transmit account data on their own systems or premises.
For e-commerce merchants, an important eligibility condition is that all elements of the payment page or form delivered to the customer's browser originate only and directly from PCI DSS-compliant third-party service providers or payment processors. The merchant website must not supply individual elements of the payment page under this eligibility condition.
SAQ A is not simply a questionnaire for every business that uses a hosted payment gateway. Merchants must meet all applicable eligibility criteria, including third-party service provider compliance and the requirements relating to the handling of account data.
SAQ A is not applicable to face-to-face payment channels or service providers. It is designed for eligible merchant environments, not as a general-purpose questionnaire for all businesses using outsourced payment services.
PCI DSS v4.0.1 SAQ A includes an eligibility criterion requiring certain e-commerce merchants to confirm that their website is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems. PCI SSC FAQ 1588 clarifies that this criterion applies to e-commerce merchants whose webpages contain an embedded third-party payment page or form, such as an iframe.
PCI SSC explains that merchants can address this criterion through appropriate techniques, including techniques aligned with PCI DSS Requirements 6.4.3 and 11.6.1, or by obtaining confirmation from the relevant compliant third-party service provider that its solution includes appropriate protections when implemented according to the provider's instructions. Merchants should review the current SAQ A and applicable PCI SSC FAQs for the complete conditions.
This particular script-related eligibility criterion does not apply in the same way to merchants that redirect customers to a third-party payment processor or fully outsource payment functions through a payment link. However, other SAQ A eligibility conditions and applicable requirements remain relevant.
PCI DSS SAQ A-EP is designed for eligible e-commerce merchants that outsource payment processing to PCI DSS-compliant third-party service providers but operate websites that can affect the security of the payment transaction or the integrity of the payment page. The merchant website does not receive account data, and the merchant does not electronically store, process, or transmit account data on its systems or premises.
The important distinction is that the merchant website plays a more direct role in controlling the payment experience. For example, the merchant website may generate or control parts of the payment page and direct customers or their account data to the third-party payment processor. Even though the merchant does not receive account data, its website can influence how the payment transaction takes place.
Under SAQ A-EP eligibility criteria, each element of the payment page delivered to the customer's browser must originate from either the merchant's website or a PCI DSS-compliant third-party service provider. The merchant must also meet the other eligibility conditions, including outsourcing account-data processing and reviewing the applicable service providers' compliance documentation.
SAQ A-EP applies only to e-commerce channels and is not applicable to service providers. It includes additional requirements because the merchant's website can affect payment transaction security, even though the website itself does not receive account data.
The primary difference between SAQ A and SAQ A-EP is the merchant website's role in the payment process. SAQ A is intended for eligible environments where payment-page elements are supplied directly and exclusively by compliant third-party providers. SAQ A-EP covers eligible e-commerce environments where the merchant website can influence payment security and may supply payment-page elements.
| Comparison Area | SAQ A | SAQ A-EP |
|---|---|---|
| Primary purpose | Validate eligible merchants that fully outsource account-data functions. | Validate eligible e-commerce merchants whose websites can affect payment security. |
| Applicable channel | E-commerce and MOTO card-not-present channels. | E-commerce only. |
| Account-data processing | Fully outsourced to compliant third parties. | Fully outsourced to compliant third parties, with the stated payment-page exception. |
| Merchant website role | May provide a redirect mechanism or link, but must meet SAQ A eligibility criteria. | Can control how customers or account data are directed to the payment processor and can affect payment security. |
| Payment-page elements | All elements originate only and directly from compliant third-party service providers. | Each element originates from either the merchant website or a compliant third-party service provider. |
| Merchant receives account data | No electronic receipt, storage, processing, or transmission of account data on merchant systems or premises. | No electronic receipt, storage, processing, or transmission of account data on merchant systems or premises. |
| Payment page security impact | The merchant website may still have applicable security responsibilities, including those defined in SAQ A. | Merchant website security is a more extensive consideration because it can affect the payment transaction. |
| Script-related eligibility criterion | Specific script-attack susceptibility confirmation applies to qualifying embedded payment-page implementations under SAQ A v4.0.1. | Applicable payment-page and web-security requirements must be addressed under the questionnaire. |
| Evidence focus | Outsourcing evidence, provider AOCs, payment-flow information, and applicable merchant website controls. | Outsourcing evidence, provider AOCs, website security, payment-page integrity, and applicable technical controls. |
| Service-provider eligibility | Not applicable to service providers. | Not applicable to service providers. |
| Relative assessment scope | Generally narrower for the defined eligible environment. | Generally broader because of the merchant website's security impact. |
The exact questionnaire requirements and eligibility wording must always be checked against the current PCI DSS v4.0.1 SAQ documents. The table provides a practical comparison, not a substitute for the official eligibility criteria.
Understanding the payment integration method is essential when comparing PCI DSS SAQ A vs SAQ A-EP. The way a payment page is generated and delivered to the customer's browser can influence which questionnaire is appropriate. However, the integration method alone does not determine eligibility. Merchants must review every condition in the relevant SAQ and confirm the validation route with their compliance-accepting entity.
In a redirect-based payment flow, the customer selects a payment option on the merchant website and is redirected to a payment page hosted by a compliant third-party payment processor. The third party supplies the payment page and handles the account-data functions.
This model may be eligible for SAQ A if all relevant criteria are satisfied. The merchant website can still have security responsibilities, particularly where it controls the redirection mechanism. Merchants should not assume that redirecting customers removes every website-related PCI DSS obligation.
An iFrame integration allows a third-party payment provider to deliver a payment form inside a webpage on the merchant's website. The payment fields may be supplied by the compliant provider, while the merchant website controls the surrounding page and customer experience.
An embedded third-party payment form may qualify for SAQ A when all SAQ A eligibility conditions are met. However, the merchant must also address the applicable script-related eligibility criterion in PCI DSS v4.0.1 SAQ A for qualifying embedded payment-page implementations. PCI SSC FAQ 1588 explains the specific circumstances and acceptable approaches for confirming protection against relevant script attacks.
In a traditional Direct Post implementation, the merchant website generates some or all of the payment page that accepts customer account data. The browser then submits the payment information directly to the third-party processor. The merchant website is therefore more directly involved in the payment-page process, even though the account data may be sent to the processor rather than the merchant's server.
This type of arrangement is commonly associated with SAQ A-EP when all applicable eligibility conditions are met. The merchant website can affect the integrity of the payment page and the security of the transaction. The merchant must therefore address the additional controls and evidence included in SAQ A-EP.
| Integration Method | Payment Page Source | Potential SAQ Direction |
|---|---|---|
| Full redirect to hosted payment page | Compliant third-party provider. | Potentially SAQ A. |
| Third-party hosted iFrame | Payment form from compliant third-party provider; merchant supplies surrounding webpage. | Potentially SAQ A, subject to all criteria and applicable script-security confirmation. |
| Direct Post | Merchant website generates some or all of the payment page. | Potentially SAQ A-EP. |
| Merchant receives or stores account data electronically | Merchant-controlled environment handles account data. | SAQ A and A-EP eligibility may not be met; assess another validation route. |
These examples are indicative rather than automatic classifications. Custom JavaScript, payment-page components, hosting arrangements, redirects, scripts, APIs, and other integration details can change the assessment. A technical review of the actual payment flow is more reliable than choosing a questionnaire based only on the payment gateway's product description.
An online retailer allows customers to select products and proceed to checkout. When the customer chooses to pay, the website redirects the customer to a payment page hosted entirely by a PCI DSS-compliant payment processor. The processor handles the payment information, and the merchant does not electronically store, process, or transmit account data.
Potential direction: SAQ A. The arrangement may qualify if all SAQ A eligibility criteria are met, including the requirement that payment-page elements originate only and directly from the compliant third-party provider. The merchant should also assess the security of its redirection mechanism and applicable website requirements.
A merchant displays a payment form inside its checkout page using an iFrame supplied by a PCI DSS-compliant payment provider. The merchant website does not receive account data, but its webpage contains the embedded payment form and surrounding scripts.
Potential direction: SAQ A. This may be eligible when all SAQ A criteria are satisfied. The merchant must pay particular attention to the v4.0.1 SAQ A script-attack susceptibility eligibility criterion and obtain or maintain appropriate evidence supporting the required confirmation.
An online store generates the checkout payment page on its own website. Customers enter their payment information into fields presented by the merchant website, and the browser submits the data directly to the third-party processor. The merchant server does not receive or store the account data.
Potential direction: SAQ A-EP. This arrangement may meet the SAQ A-EP model because the merchant website generates or controls elements of the payment page and can affect payment security. All other eligibility conditions must still be verified.
A business uses an external payment gateway but also stores customers' full payment card numbers electronically in its own database for recurring transactions or internal processing.
Potential direction: Neither SAQ A nor SAQ A-EP should be assumed eligible. Electronic storage of account data may invalidate the eligibility conditions for both questionnaires. The merchant must evaluate its actual data flows and applicable PCI DSS validation requirements. Another assessment route, potentially SAQ D or a ROC, may be required depending on the environment and compliance program.
A merchant sends customers a payment link that directs them to a third-party payment provider. The provider hosts the payment page and handles all account-data processing. The merchant's website does not generate payment-page elements or receive account data through the payment process.
Potential direction: SAQ A. This model may be eligible if the merchant meets all SAQ A requirements for its payment channel and confirms the correct validation route with its acquiring bank or other compliance-accepting entity.
The following decision table provides a practical starting point for selecting between SAQ A and SAQ A-EP. It should be used alongside the complete PCI DSS v4.0.1 eligibility criteria, not as a substitute for them.
| Business or Technical Condition | Potential Direction | What to Verify |
|---|---|---|
| All payment-page elements come directly from a compliant third-party provider. | SAQ A | All SAQ A eligibility criteria and provider compliance for the services used. |
| Merchant website generates or supplies payment-page elements. | SAQ A-EP may be relevant. | Payment-page source, account-data flow, and all SAQ A-EP eligibility criteria. |
| Customer is redirected to a hosted payment page. | SAQ A may be relevant. | Redirection mechanism, page elements, and website security obligations. |
| Merchant uses a third-party embedded payment form. | SAQ A may be relevant. | All SAQ A conditions and the applicable script-security eligibility criterion. |
| Merchant uses Direct Post integration. | SAQ A-EP may be relevant. | Whether the merchant website generates or controls payment-page elements and whether all eligibility conditions are met. |
| Merchant electronically stores account data. | Neither may be suitable. | Actual account-data storage and applicable assessment route. |
| Merchant electronically receives or processes account data. | Neither may be suitable. | Data flow, system scope, and applicable SAQ or ROC requirements. |
| Merchant is a service provider rather than a merchant. | Neither SAQ A nor SAQ A-EP. | Applicable service-provider validation requirements. |
Selecting an SAQ is only one part of the validation process. Merchants also need reliable evidence to support their eligibility, demonstrate the implementation of applicable controls, and document the results of their assessment. Evidence should reflect the actual payment environment rather than relying solely on statements from a payment gateway or website developer.
| Evidence Type | SAQ A Considerations | SAQ A-EP Considerations |
|---|---|---|
| Payment flow diagram | Shows the redirect or hosted payment process. | Shows how merchant-controlled website elements interact with payment processing. |
| Third-party provider AOC | Confirms provider compliance for the services used. | Confirms provider compliance for the payment services and hosting arrangements where applicable. |
| Website and payment-page documentation | Supports confirmation that payment-page elements originate from compliant third parties. | Supports analysis of merchant-controlled payment-page elements and security responsibilities. |
| Script-security evidence | Relevant for qualifying embedded payment-page implementations under the SAQ A v4.0.1 eligibility criterion. | Supports applicable payment-page and web-security controls. |
| Vulnerability scanning records | Applicable external scanning evidence must be reviewed for merchant e-commerce websites, including qualifying redirects and embedded forms. | Supports applicable vulnerability scanning and testing requirements. |
| Access and configuration records | Supports applicable merchant website and system controls. | Supports the broader set of applicable website and system security controls. |
| Policies and procedures | Documents applicable security responsibilities and processes. | Documents applicable security, configuration, and operational responsibilities. |
For SAQ A and SAQ A-EP, external vulnerability scanning requirements must not be overlooked. PCI SSC FAQ 1604 clarifies that PCI DSS v4.x SAQ A includes applicable external vulnerability scanning requirements for merchant e-commerce webpages, even when payment processing is fully outsourced. Where required under PCI DSS, the scans must be performed by a PCI SSC Approved Scanning Vendor (ASV).
Evidence should be current, relevant to the assessed environment, and traceable to the applicable requirement. A provider's AOC does not automatically demonstrate that the merchant has implemented its own responsibilities or that the provider's specific service is covered by the provider's validated scope.
Merchants should understand the difference between a Self-Assessment Questionnaire, a Report on Compliance, and an Attestation of Compliance before starting a PCI DSS validation project.
A merchant should not assume that it can select SAQ A or SAQ A-EP solely because its technical arrangement appears to match a particular example. The acquiring bank, payment brand, or other entity responsible for accepting compliance validation may specify the required reporting route and additional instructions.
Merchants completing an SAQ are responsible for ensuring that their self-assessment is accurate and supported by appropriate evidence. A QSA may provide professional assessment services where required or engaged, but the merchant remains responsible for providing accurate information about its environment and meeting its obligations. ASVs perform the applicable external vulnerability scanning activities within their approved role; an ASV scan is not a substitute for a full PCI DSS assessment.
For this reason, merchants should confirm who is responsible for selecting the validation route, reviewing the SAQ, performing any required independent assessment, and accepting the final compliance documentation before committing to a particular questionnaire.
Even when a merchant uses a well-known payment provider, its PCI DSS scope depends on the complete payment environment. Website hosting, third-party scripts, content delivery networks, access privileges, redirect mechanisms, payment-page construction, and connected systems may all influence the security of the transaction.
No. SAQ A and SAQ A-EP are not equivalent, interchangeable, or automatic substitutes for each other. They are separate PCI DSS validation questionnaires developed for different merchant environments. Each has its own eligibility criteria, applicable requirements, and evidence expectations.
A merchant that meets the eligibility criteria for SAQ A cannot automatically use SAQ A-EP as proof of a different assessment scope. Similarly, a merchant whose website controls or generates payment-page elements cannot simply select SAQ A to reduce the number of applicable questions if its implementation does not meet SAQ A eligibility requirements.
The questionnaires also do not prove that a merchant has no payment-security responsibilities outside the questions included in the selected SAQ. PCI DSS scope and validation obligations must be determined based on the actual environment and the applicable compliance program. Where a merchant's environment does not meet the eligibility criteria for either questionnaire, another assessment route may be necessary.
Selecting between SAQ A and SAQ A-EP requires more than reviewing a payment gateway contract. Organizations need to understand their payment architecture, account-data flows, website responsibilities, third-party service provider relationships, and applicable PCI DSS requirements.
B-ADVANCY Certification UK Limited supports organizations through management-system certification, audits and inspections, consulting, calibration and testing, and professional training. Organizations exploring payment security and related assurance requirements can benefit from a structured discussion to understand their business objectives, scope considerations, and appropriate next steps.
A PCI DSS scope and gap-assessment discussion should consider:
The objective is to help organizations understand their scope and prepare an appropriate assessment plan without guaranteeing compliance or treating a preliminary gap review as a formal PCI DSS validation. Where independent assessment is required, the responsibilities of the relevant qualified assessor must be clearly established.
13. Frequently Asked Questions (FAQs)
SAQ A is designed for eligible merchants that fully outsource account-data functions and, for e-commerce, use payment-page elements supplied only and directly by compliant third parties. SAQ A-EP is designed for eligible e-commerce merchants whose websites can affect payment security and may supply payment-page elements.
Potentially, yes. The merchant must meet all SAQ A eligibility criteria, including outsourcing account-data processing, not electronically storing, processing, or transmitting account data, and ensuring that payment-page elements originate directly and exclusively from compliant third-party providers for the e-commerce channel.
It may be eligible if all SAQ A criteria are met. For qualifying embedded payment forms, merchants must also address the SAQ A v4.0.1 eligibility criterion concerning susceptibility to script attacks, as clarified by PCI SSC FAQ 1588.
Direct Post implementations are commonly associated with SAQ A-EP because the merchant website generates or controls some or all of the payment page. However, the merchant must verify every SAQ A-EP eligibility condition against its actual implementation.
No. SAQ A merchants remain responsible for the applicable requirements included in the questionnaire, maintaining appropriate third-party service provider oversight, and addressing relevant website security obligations. Outsourcing payment processing does not remove every merchant responsibility.
Not necessarily. SAQ A-EP is designed for eligible merchants whose websites can affect payment transaction security, even though the website does not receive account data and account-data processing is outsourced to compliant third parties.
Generally, electronic storage of account data is inconsistent with the SAQ A eligibility criteria. The merchant should assess its actual environment and determine the appropriate PCI DSS validation route rather than assuming SAQ A or SAQ A-EP applies.
PCI DSS v4.x SAQ A includes applicable external vulnerability scanning requirements for merchant e-commerce webpages, including qualifying redirect and embedded payment-page implementations. Where required, the scan must be performed by a PCI SSC Approved Scanning Vendor.
No. SAQ selection must be based on the actual payment environment and complete eligibility criteria, not on the number of questions. Choosing an ineligible questionnaire can result in inaccurate compliance reporting.
The merchant should review the official PCI SSC SAQ eligibility criteria and confirm the required validation route with its acquiring bank, payment brand, or other compliance-accepting entity. A qualified assessor may provide technical assessment guidance where applicable, but the entity responsible for accepting compliance documentation determines its program requirements.
Understanding PCI DSS SAQ A vs SAQ A-EP is essential for e-commerce merchants that outsource payment processing but still operate websites that may influence payment security. SAQ A is intended for eligible environments where payment-page elements are supplied directly and exclusively by compliant third-party providers. SAQ A-EP addresses eligible e-commerce environments where the merchant website can affect payment transaction security and may generate or control payment-page elements.
The correct choice depends on the actual payment architecture, account-data flow, website responsibilities, third-party provider arrangements, and complete eligibility criteria. Merchants should also review PCI DSS v4.0.1 updates, applicable script-security conditions, external vulnerability scanning obligations, and their acquiring bank's validation instructions.
Most importantly, SAQ A and SAQ A-EP are not interchangeable. Meeting the eligibility criteria for a questionnaire does not itself guarantee compliance, and outsourcing payment processing does not eliminate all merchant security responsibilities. A structured scope review, accurate evidence collection, and confirmation of the correct SAQ or ROC validation route help organizations approach PCI DSS compliance more effectively and responsibly
Request a PCI DSS scope/gap-assessment discussion with B-ADVANCY to review your payment environment, clarify the appropriate SAQ or ROC validation route, and identify the evidence and assessor responsibilities applicable to your organization.
