Merchants often meet SAQ A-EP by surprise. They built the checkout the way the processor’s quick-start suggested, a card form on their own page posting straight to the processor, and assumed that because card numbers never touch their server, SAQ A applies. The card-data part is true. The conclusion is not. This guide lays out A-EP eligibility in full, explains the reasoning behind it, and shows how to confirm which questionnaire is actually yours.
What SAQ A-EP is
A PCI Self-Assessment Questionnaire (SAQ) is a validation document from the PCI Security Standards Council (PCI SSC). You complete the one that matches how you accept cards, then sign an Attestation of Compliance (AOC) that goes to your acquiring bank or the card brands. There are eight SAQ types; the full map lives in our guide to all 8 SAQ types.
SAQ A-EP is written for e-commerce merchants that partially outsource payment processing to a PCI DSS validated third party. The defining trait: your website does not itself receive cardholder data, but it can affect the security of the transaction. A validated processor still does the card processing; your site plays a part in how the card data gets collected.
“Partially outsourced” is the operative phrase. A fully outsourced checkout, where the processor hosts the entire payment page and your site just sends the customer there, points to SAQ A instead. And note the channel: SAQ A-EP is e-commerce only. SAQ A also covers fully outsourced mail order/telephone order; A-EP has no MOTO version.
Who SAQ A-EP fits
Merchants who belong on SAQ A-EP usually describe their checkout in one of two ways:
- “Checkout is a form on my own site, and the card number goes straight to my processor.” A direct-post form: your website serves the payment form, and the form’s action submits the card data from the customer’s browser to the processor. Your server never receives it.
- “My page loads the processor’s JavaScript, and the script sends the card data.” A JavaScript form: code running in your page collects the card number in the browser and transmits it to the processor. The data path skips your server; the code came from your site.
The common thread: your website originates the page, form, or script the customer pays through; a PCI DSS validated third party does the processing; and no system you control receives or stores cardholder data. That combination is SAQ A-EP’s territory.
What “your website can affect transaction security” means
The phrase comes straight from the eligibility definition, and it is the whole reason SAQ A-EP exists, so it is worth unpacking properly.
Follow the card number in a direct-post or JavaScript checkout. The customer types it into a form on your page. When they pay, the data travels from their browser to the processor. Your server is not in that path, and nothing is stored on your side. Looking only at the data flow, your site seems out of the picture.
Now follow everything else. Your site delivered the page the customer typed into. Your site delivered the form and where it posts, or the script that collects the digits. Every element the customer’s browser executes at the moment of payment originated from systems you control. Whoever can change your website can change all of it: where the form posts, what the script does with the number, what else loads alongside it. Card data could be collected differently without your server ever seeing a card number.
That is influence, and PCI DSS scopes for influence, not just data flow. Your website can affect the security of the transaction even though it does not itself receive cardholder data. That sentence is the hinge of A-EP eligibility, and it is why the questionnaire reaches your website and the systems that serve it rather than stopping at “no card data here.”
The practical consequence: SAQ A-EP asks meaningfully more of you than SAQ A does. Not because you handle card data, you don’t, but because your site’s integrity became part of the transaction’s security the moment your site started delivering the payment form.
The exact eligibility criteria
Strip away the examples and SAQ A-EP eligibility comes down to this list. All of it has to be true:
- Your acceptance channel is e-commerce. Other channels validate under other SAQ types.
- Payment processing is partially outsourced to a PCI DSS validated third party. The processor does the processing; your providers should be able to show current PCI DSS validation.
- Your website does not receive cardholder data. If a card number ever posts to or passes through a server you control, even in transit, even unstored, you are outside A-EP.
- No system you control stores cardholder data electronically. A database, a spreadsheet, an application log, a call recording: electronic storage generally moves you to SAQ D, whatever your checkout looks like.
Honest limit: the SAQ A-EP document itself carries the authoritative eligibility checklist for the PCI DSS version you validate against, and your acquiring bank confirms which questionnaire it will accept from you. This guide is the plain-language version, not the paperwork.
The boundary with SAQ A, from this side
Two merchants, same processor, same true statement: “card data never lands on our server.” One validates SAQ A, the other SAQ A-EP. The deciding question is always the same: whose systems deliver the page, frame, or script that collects the card number?
- Full redirect to a processor-hosted payment page: the payment content originates from the processor. SAQ A side.
- Provider-hosted iframe: your page embeds a frame whose contents, the payment form itself, are served from the processor’s systems. SAQ A side.
- Direct-post form served from your website, posting card data straight to the processor: your site delivered the form. SAQ A-EP side.
- JavaScript form: script in your page collects the card number and sends it to the processor. Your site delivered the code. SAQ A-EP side.
Stepping down to SAQ A is an architectural move, not a paperwork one: replace the on-site form with a full redirect or a provider-hosted iframe so that all payment content originates from the processor. Some merchants make that trade. Others keep the on-site form because they want that checkout experience, and validate A-EP as designed. Both are legitimate paths. What does not work is keeping an A-EP checkout and attesting to SAQ A.
The boundary runs the other way too. If your form posts card data to your own server first, which then forwards it to the processor, your systems are transmitting cardholder data. That is not partial outsourcing, and it is outside every reduced e-commerce SAQ; SAQ D generally applies.
And a caution about vendor names: “embedded fields,” “drop-in,” “hosted fields,” and similar labels are marketing, not eligibility rulings. Implementations differ, and the mechanics decide. Check your provider’s PCI documentation for the SAQ your integration type maps to, and confirm with your acquiring bank. If you build on a platform, our Stripe, WooCommerce, and Shopify guides cover the common cases.
Not sure which side of the line you’re on?
The free check asks how your checkout actually works and computes your likely SAQ on screen in about two minutes. No email to see the result, no card, nothing to install. It is indicative, not a QSA assessment, and it beats validating against the wrong questionnaire in either direction.
What else disqualifies you
Beyond receiving card data on your own systems, watch for these:
- Storing cardholder data electronically. Anywhere in your environment, including the places people forget: exports, application logs, call recordings, a spreadsheet kept “just in case.” Electronic storage generally means SAQ D.
- A card-present channel. Add a terminal and that channel validates under the terminal-oriented SAQs: SAQ B, SAQ B-IP, SAQ P2PE, or the SAQ C family. Multi-channel environments can span more than one SAQ; your bank tells you how to validate the whole picture.
- Phone orders keyed into your systems. SAQ A-EP is e-commerce only. Staff keying one transaction at a time into an isolated, third-party-hosted virtual terminal points to SAQ C-VT. Keying card numbers into applications you run means you are processing cardholder data yourself.
- An unvalidated third party. Eligibility rests on outsourcing to PCI DSS validated providers. A processor that cannot show current validation breaks the chain.
What you actually answer
SAQ question counts vary by PCI DSS version, so we will not quote one. Qualitatively: a shorter SAQ covers fewer requirements, and SAQ A-EP sits well above SAQ A because your website is in scope, while still stopping short of the full requirement set that SAQ D carries.
The universe the questions draw from is the 12 PCI DSS requirements across 6 goals. For A-EP, expect the questionnaire to reach the website and whatever serves it: keeping the site and its underlying systems maintained and patched, controlling who can log in and change things, noticing when something on the payment path changes, testing, and having your security practices written down. The exact set depends on the version you validate against; the SAQ A-EP document spells it out.
One timing note. PCI DSS v4.0 was published in March 2022, v3.2.1 retired on March 31, 2024, and all of v4.0’s future-dated requirements became mandatory on March 31, 2025. Answer this year’s questionnaire against the current requirement set; our v4.0 deadlines guide has the full timeline.
Completing the SAQ ends the same way for everyone: you sign the Attestation of Compliance and submit it to your acquiring bank or the card brands.
How to confirm SAQ A-EP is yours
Two confirmations count. Your acquiring bank assigns your validation level from your annual card volume and tells you which questionnaire it will accept; most small and mid-size merchants validate with an SAQ, while the highest-volume merchants go through a QSA-led Report on Compliance. A Qualified Security Assessor (QSA) can give you an assessor’s judgment when the integration genuinely is not clear-cut.
Walk into either conversation knowing your likely answer and why. That is what the free check and the full analysis are for.
Confirm your SAQ, then close the gaps.
The free check names your likely SAQ on screen in about two minutes, no email needed to see the result. When you want it confirmed with rationale, the $1,495 PCI DSS v4.0 Readiness & Gap Analysis documents your SAQ determination, marks each of the 12 PCI DSS v4.0 requirements covered, partial, or gap for your environment, and hands you a prioritized 30/60/90 remediation roadmap. PDF in your inbox within hours, backed by a 7-day pre-delivery money-back guarantee, and the $1,495 credits toward a first month of an Aegis AI subscription at ai4ciso.ai.
Frequently asked questions
What is the difference between SAQ A and SAQ A-EP?
Both describe e-commerce merchants using a PCI DSS validated processor, and in both the card number goes from the customer’s browser to the processor without landing on the merchant’s server. The difference is who delivers the payment content. A full redirect or a provider-hosted iframe means the payment page originates from the processor, which points to SAQ A. A direct-post or JavaScript form served from your own website points to SAQ A-EP, because your site can affect the security of the transaction.
My processor is PCI DSS compliant. Doesn’t that cover my website?
Their validation covers their systems, not yours. SAQ A-EP exists precisely because your website can affect the security of the transaction even when a validated third party does all the processing. You still validate your own side and submit your own Attestation of Compliance.
What if card data passes through my server but is never stored?
Then your systems are transmitting cardholder data and you are outside SAQ A-EP, which requires that your website does not receive cardholder data at all. A checkout that posts card data to your server, even briefly and even without storage, generally points to SAQ D.
Can I move from SAQ A-EP to SAQ A?
Possibly. Replacing an on-site payment form with a full redirect or a provider-hosted iframe means the payment content originates from the processor’s systems, which is the SAQ A pattern. Confirm the change with your provider’s PCI documentation and your acquiring bank before you validate against a different questionnaire.
Is SAQ A-EP only for e-commerce?
Yes. SAQ A-EP is written for e-commerce merchants that partially outsource payment processing to a PCI DSS validated third party. Fully outsourced mail order/telephone order acceptance falls under SAQ A, and other acceptance channels validate under other SAQ types.
Who confirms which SAQ I complete?
Eligibility for each SAQ is defined by the PCI Security Standards Council, and your acquiring bank or card brand confirms which questionnaire it will accept and your validation level. Our free check computes your likely SAQ from how you accept cards; it is indicative, not a QSA assessment.
Related guides
Or browse every PCI DSS guide in one place.
This guide is general information, not a QSA assessment, a completed SAQ, an Attestation of Compliance, or legal advice. Confirm your SAQ and obligations with your acquiring bank or a Qualified Security Assessor.