Skip to main content
Commerce Security Authority
Category: PCI DSS Compliance

SAQ A-EP

Also known as: SAQ A-EP, Self-Assessment Questionnaire A-EP, SAQ A-EP Attestation of Compliance
Simply put

SAQ A-EP is a PCI DSS self-assessment questionnaire for e-commerce merchants who accept card-not-present payments and have handed off part—but not all—of their online payment process to PCI DSS validated third parties. It applies when the merchant's own website still plays a role in how payment data is captured or transmitted, so the merchant retains more security responsibility than the simpler SAQ A. Merchants using it must confirm their web pages are secure and do not introduce vulnerabilities into the payment process.

Formal definition

SAQ A-EP is a self-assessment questionnaire and attestation applicable to e-commerce merchants that partially outsource their e-commerce payment channel to PCI DSS validated and compliant third-party service providers, but whose website can affect the security of the payment transaction. It is distinguished from SAQ A—which typically covers full outsourcing via iframe or redirect implementations where the merchant page does not directly handle cardholder data—in that SAQ A-EP generally applies to implementations such as direct-post or JavaScript-generated payment forms served from the merchant's site. Because the merchant's web infrastructure participates in the payment flow, SAQ A-EP carries a broader control set than SAQ A, requiring merchants to verify that their webpages are secure and do not introduce vulnerabilities into the payment process. It is limited to card-not-present (e-commerce) transactions and does not apply to card-present acceptance. Applicability, eligibility criteria, and the specific requirements included differ between PCI DSS versions (for example, v3.x versus v4.0); merchants should confirm eligibility and control coverage against the current published SAQ A-EP document and consult their acquirer or the applicable card brand for validation obligations.

Why it matters

SAQ A-EP addresses a category of e-commerce risk that the simpler SAQ A does not cover: implementations where a merchant has outsourced payment processing to a PCI DSS validated third party, but where the merchant's own website still participates in how payment data is captured or transmitted. In these arrangements—commonly direct-post or JavaScript-generated payment forms served from the merchant's site—the security of the merchant's web infrastructure can directly affect the security of the payment transaction. If the merchant's pages are compromised, an attacker may be able to intercept or redirect cardholder data even though the merchant does not intend to handle or store it.

This distinction matters because choosing the wrong SAQ can leave real risk unaddressed. A merchant that assumes a redirect-style SAQ A applies when its implementation actually places the merchant page in the payment flow would validate against a narrower control set than its architecture warrants. SAQ A-EP requires merchants to verify that their webpages are secure and do not introduce vulnerabilities into the payment process, reflecting the broader responsibility that comes with retaining a role in payment data capture or transmission.

Because eligibility criteria and the specific requirements included differ between PCI DSS versions—for example, v3.x versus v4.0—merchants should confirm which SAQ applies against the current published SAQ A-EP document and consult their acquirer or the applicable card brand for validation obligations. Selecting the appropriate questionnaire is a scoping decision that depends on the actual technical implementation, not on the label a payment integration is marketed under.

Who it's relevant to

E-commerce merchants
Online merchants that accept card-not-present payments and have outsourced part of their payment processing to a PCI DSS validated third party, while their own website still plays a role in capturing or transmitting payment data. This commonly includes direct-post and JavaScript-generated payment form implementations, as distinct from full iframe or redirect outsourcing that may fall under SAQ A.
Compliance officers and QSAs
Those responsible for scoping and validating a merchant's e-commerce channel need to distinguish SAQ A-EP from SAQ A based on the actual technical implementation. The decision hinges on whether the merchant's webpages can affect the security of the payment transaction, and eligibility should be confirmed against the current published SAQ document and relevant PCI DSS version.
Acquirers and payment processors
Acquirers set and enforce validation obligations for their merchants and can confirm which SAQ applies to a given integration. Merchants should consult their acquirer or the applicable card brand regarding validation requirements, since these obligations vary and change over time.
Web developers and security engineers
Teams building and maintaining merchant payment pages carry responsibility under SAQ A-EP for keeping those pages secure and free of vulnerabilities that could compromise the payment process. Because the merchant's web infrastructure participates in the payment flow, secure development, change management, and monitoring of scripts and page components are within scope.

Inside SAQ A-EP

Applicability to e-commerce merchants
SAQ A-EP is a self-assessment questionnaire intended for e-commerce merchants that partially outsource cardholder data functions to PCI DSS validated third-party service providers but whose website itself can affect the security of the payment transaction. It does not apply to card-present channels or to merchants who fully outsource such that their site has no impact on the transaction.
Distinction from SAQ A
SAQ A-EP covers merchants whose own website influences how payment data is captured or delivered to the payment processor, for example where the merchant server creates or controls the payment form or redirect. SAQ A, by contrast, is intended for merchants who fully outsource so that their environment does not receive or affect cardholder data. Confirm the current eligibility criteria against the published SAQ documentation, as wording and conditions differ between versions.
No electronic storage of cardholder data
Eligibility typically requires that the merchant does not electronically store, process, or transmit any cardholder data on its systems, though its website may affect the transaction. Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs must not be stored after authorization under any SAQ. Cardholder data such as PAN is subject to defined controls where present.
Broader control set than SAQ A
Because the merchant website can affect transaction security, SAQ A-EP contains a substantially larger set of PCI DSS requirements than SAQ A, addressing areas such as secure systems and software, access control, logging and monitoring, and vulnerability management. Requirement numbering and wording vary by PCI DSS version, so confirm the applicable set against the current published standard.
Reliance on validated service providers
SAQ A-EP presumes payment processing functions are handled by third parties whose PCI DSS compliance is validated. The merchant remains responsible for managing service provider relationships and for the security of components under its control, such as the web server and any scripts it serves.

Common questions

Answers to the questions practitioners most commonly ask about SAQ A-EP.

Is SAQ A-EP the same as SAQ A because both apply to e-commerce merchants who outsource payment processing?
No. Although both are self-assessment questionnaires for card-not-present e-commerce merchants who do not store, process, or transmit cardholder data on their own systems, they address different implementations. SAQ A generally applies where all elements of the payment page are delivered directly from a validated third party, so the merchant's website does not influence the security of the payment data. SAQ A-EP applies to merchants whose website does not directly handle cardholder data but does affect the security of the payment transaction, for example by delivering or controlling elements of the page that redirects or embeds the payment form. Because the merchant's environment can influence how payment data is captured, SAQ A-EP includes more applicable requirements than SAQ A. Confirm the current eligibility criteria and requirement set against the SAQ documents published for the version of PCI DSS you are validating against.
Does using SAQ A-EP mean my systems never touch cardholder data, so the payment data is out of scope?
Not exactly. SAQ A-EP applies precisely because the merchant website can affect the security of the payment transaction even though it does not directly store, process, or transmit cardholder data on the merchant's own servers. The merchant's web infrastructure is in scope for the applicable controls because a compromise of that environment could alter how cardholder data is captured or redirected. Eligibility for SAQ A-EP does not remove the merchant's responsibility for the systems that influence the payment flow. Determine scope based on how your implementation actually handles and influences the payment page, and validate against the current SAQ A-EP eligibility criteria rather than assuming the label removes all payment data from scope.
How do I determine whether my e-commerce setup qualifies for SAQ A-EP rather than another SAQ or a full assessment?
Review the eligibility criteria stated in the current SAQ A-EP document and compare them to how your website interacts with the payment flow. Key considerations include whether your site directly handles cardholder data, whether it delivers or controls elements of the payment page, and how the payment form is presented, such as through a redirect, an embedded iframe, or direct post to a third party. Your acquirer or the relevant card brand may also specify which validation method they require. Because eligibility wording and options can differ between PCI DSS versions, confirm the criteria against the published SAQ for your applicable version, and consult your acquirer if the appropriate SAQ is unclear.
What kinds of controls should I expect to address when completing SAQ A-EP?
SAQ A-EP typically covers a broader set of requirements than SAQ A because the merchant's own web environment can influence the security of the payment transaction. Expect controls related to the security of the systems that deliver or affect the payment page, such as protecting internet-facing systems, managing vulnerabilities, controlling access, logging and monitoring, and maintaining secure configurations, among others. The exact requirements, their numbering, and their wording differ between PCI DSS versions, so work from the specific SAQ A-EP document for the version you are validating against rather than assuming a fixed list.
How does the way my payment page is integrated affect which SAQ I use?
The integration method is central to SAQ selection for e-commerce merchants. Implementations where all payment page content is served directly by a validated third party, so the merchant site does not influence the capture of cardholder data, may point toward SAQ A. Implementations where the merchant's website delivers or controls part of the page or otherwise affects how the payment form is presented tend to point toward SAQ A-EP, because the merchant environment can influence transaction security. Because the security implications depend on the actual implementation and not on the label of the technique, document precisely how your page is constructed and delivered, and confirm the applicable SAQ against current guidance and with your acquirer.
If I later change my payment page integration, do I need to reassess which SAQ applies?
Yes, changes to how your website delivers or influences the payment page can change your eligibility and the applicable SAQ. Moving between a fully redirected or hosted model and one where your site delivers or controls page elements can shift you between SAQ A and SAQ A-EP, and other changes may affect scope more broadly. Reassess your validation approach whenever you alter the payment flow, and confirm the correct SAQ against the current published criteria and with your acquirer, since eligibility criteria and requirements can differ between PCI DSS versions.

Common misconceptions

Using a redirect or iframe to a payment processor automatically qualifies a merchant for the simpler SAQ A.
Whether a merchant qualifies for SAQ A or SAQ A-EP depends on how the payment page is served and controlled, not solely on the presence of a redirect or iframe. If the merchant server creates or controls elements that affect how payment data is captured or delivered, SAQ A-EP may apply. Eligibility criteria differ between versions, so confirm against the current published SAQ documentation.
Because no cardholder data is stored, the merchant's website is out of scope and needs minimal controls.
SAQ A-EP exists precisely because the website can affect transaction security even when the merchant does not store cardholder data. It carries a broader set of requirements than SAQ A, covering areas such as secure development, access control, logging, and vulnerability management for components the merchant controls.
Completing SAQ A-EP guarantees the merchant cannot be involved in a payment page compromise.
Self-assessment attests to controls at a point in time and is intended to reduce risk; it does not guarantee that client-side scripts or web server components cannot be tampered with. Ongoing monitoring, change management, and script integrity practices help mitigate but do not eliminate this risk.

Best practices

Confirm your correct SAQ type against the current published PCI DSS SAQ eligibility criteria before self-assessing, since the distinction between SAQ A and SAQ A-EP depends on how your website affects the transaction and criteria differ between versions.
Verify and document that your third-party payment service providers are PCI DSS validated, and maintain written agreements clarifying which party is responsible for which controls.
Ensure sensitive authentication data is never stored after authorization and confirm that no cardholder data is electronically stored, processed, or transmitted on systems you intend to keep out of eligible scope.
Apply the broader control set required by SAQ A-EP to the web server and any scripts you serve, including secure configuration, access control, logging and monitoring, and vulnerability management, checking the specific applicable requirements against the current standard.
Implement change management and integrity monitoring for payment page components and client-side scripts to help detect unauthorized modifications, recognizing these controls reduce but do not eliminate tampering risk.
Reassess your SAQ eligibility whenever you change how your payment page is served or integrated, as such changes can move you between SAQ types.