Compliance Assessment ToolSAQ A-EP: who needs it?
SAQ A-EP is for online stores whose own website shows the checkout page, even though the card number itself goes straight to the payment provider and never lands on your server.
This is probably you if…
- You only take online payments.
- Your website renders the payment page, but the card fields or the form submission go directly to your payment provider.
- Your servers never receive or store the card number.
Typical setups
- Stripe Elements or Stripe.js embedded in your own checkout page.
- Braintree Hosted Fields, Authorize.net Accept.js, Adyen Drop-in and similar "fields inside your page" integrations.
- A "direct post" form on your site that submits straight to the processor.
It's probably not SAQ A-EP if…
- Customers are redirected to the provider's own checkout page — that is usually SAQ A.
- Card numbers ever reach your server, database or logs — that is SAQ D.
Not sure it's SAQ A-EP?
Describe how you take payments in your own words and we'll check it against every SAQ's conditions — free. If it is SAQ A-EP, we walk you through it in plain English and produce your signed SAQ and Attestation of Compliance.
Check my SAQ — free →The official eligibility criteria
To use SAQ A-EP, the PCI Security Standards Council requires all of the following:
- The merchant accepts only e-commerce transactions;
- All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant third-party service provider (TPSP)/payment processor;
- The merchant's e-commerce website does not receive account data but controls how customers, or their account data, are redirected to a PCI DSS compliant TPSP/payment processor;
- If the merchant website is hosted by a TPSP, the TPSP is compliant with all applicable PCI DSS requirements (including PCI DSS Appendix A if the TPSP is a multi-tenant hosting provider);
- Each element of the payment page(s) delivered to the customer's browser originates from either the merchant's website or a PCI DSS compliant TPSP;
- The merchant does not electronically store, process, or transmit any account data on merchant systems or premises, but relies entirely on a TPSP(s) to handle all these functions;
- The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and has confirmed that the TPSP(s) are PCI DSS compliant for the services used by the merchant; and
- Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.
Questions people ask
Why is SAQ A-EP longer than SAQ A if card numbers never touch my server?
Because your site controls the page the customer pays on. If that page were tampered with — a malicious script, a hijacked redirect — card numbers could be stolen even though your server never stores them. SAQ A-EP covers protecting that page.
Can I switch from SAQ A-EP to SAQ A?
Often, by moving to your provider's fully hosted checkout so the customer leaves your site to pay. Confirm the change with your acquirer.
Other SAQ types
SAQ A · SAQ B · SAQ B-IP · SAQ C · SAQ C-VT · SAQ P2PE · SAQ SPoC · SAQ D
This guide helps you identify the right self-assessment questionnaire. Your acquiring bank or payment processor decides which SAQ you must submit — confirm with them if you are unsure. Compliance Assessment Tool helps you complete a PCI DSS self-assessment; we are not a Qualified Security Assessor (QSA) and do not certify compliance. Eligibility criteria quoted from PCI DSS v4.0.1 SAQ A-EP documentation published by the PCI Security Standards Council.