If a validated provider hosts your payment page and your own systems never store, process, or transmit a card number, SAQ A is probably the questionnaire your acquiring bank expects. Probably is the operative word. The line between SAQ A and its neighbor SAQ A-EP comes down to one implementation detail, and it is easy to misread in both directions. This guide lays out the eligibility criteria in full, walks that boundary precisely, and shows you how to confirm where you stand.
What SAQ A 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, and you finish by signing an Attestation of Compliance (AOC) that goes to your acquiring bank or the card brands. There are eight SAQ types; if you want the full map first, start with our guide to all 8 SAQ types.
SAQ A is the questionnaire for card-not-present merchants, meaning e-commerce or mail order/telephone order (MOTO), that have fully outsourced every cardholder-data function to PCI DSS validated third parties. Your systems never store, process, or transmit cardholder data. Because the card-data work sits with your providers, SAQ A asks the least of your own systems of any SAQ: fewer of the controls are yours to operate, so fewer of the questions are yours to answer.
One thing SAQ A is not: an exemption. PCI DSS applies to every merchant that accepts payment cards. SAQ A is the lightest way to validate, not a pass on validating.
Who SAQ A fits
You will recognize your setup faster in scenarios than in eligibility language. Merchants who belong on SAQ A usually describe their checkout one of three ways:
- “Customers leave my site to pay.” Checkout hands the customer off to a payment page your processor hosts, and the browser comes back to your site after the charge. Your pages never ask for a card number.
- “The card form in my checkout is a frame my provider hosts.” Your page embeds an iframe, and everything inside it, the fields, the validation, the submit, is delivered by the processor from the processor’s systems. The customer types the card number into the provider’s page shown within yours.
- “A validated third party takes our phone and mail orders end to end.” You sell card-not-present by MOTO, and the people and systems that handle card data all belong to PCI DSS validated providers, not to you.
The common thread: in every one of these, no system you control ever stores, processes, or transmits cardholder data, and every party doing that work for you is PCI DSS validated. That pair of facts is the entire foundation of SAQ A.
The exact eligibility criteria
Strip away the examples and SAQ A eligibility comes down to a short list. All of it has to be true, not most of it:
- Your acceptance is card-not-present only. E-commerce, mail order, or telephone order. Any card-present acceptance, a terminal at a counter for example, validates under other SAQ types, not under SAQ A.
- All cardholder-data functions are fully outsourced. The payment page, the processing, any storage: every function that touches card data is performed by third parties on their systems.
- Those third parties are PCI DSS validated. Outsourcing to an unvalidated provider does not preserve SAQ A eligibility. Your providers should be able to show current PCI DSS validation.
- Your systems never store, process, or transmit cardholder data. Not at checkout, not in a database, not in an export, not in a log.
And the override that sits on top of every reduced SAQ: if any system you control stores cardholder data electronically, a database, a spreadsheet, an application log, a call recording, the reduced SAQs are off the table and SAQ D generally applies.
Honest limit: the SAQ A document itself carries the authoritative eligibility checklist for the PCI DSS version you validate against, and your acquiring bank confirms that SAQ A is the questionnaire it will accept from you. Treat this guide as the plain-language version, not the paperwork.
SAQ A or SAQ A-EP: the boundary, precisely
This is where most of the confusion lives, so here it is with no rounding. Both SAQ A and SAQ A-EP describe e-commerce merchants using a validated processor. In both, the customer’s card number travels from the customer’s browser to the processor and never lands on your server. The difference is a single question: whose systems deliver the page, frame, or script that collects the card number?
On the SAQ A side:
- Full redirect. The customer’s browser leaves your site, and the payment page is the processor’s own. Everything the customer sees and types into at the moment of payment originates from the processor.
- Provider-hosted iframe. Your page embeds a frame, but the contents of the frame, the payment form itself, are served by the processor from its systems. Your page is the picture frame, not the painting.
On the SAQ A-EP side:
- Direct-post form. Your website serves the payment form, and the form’s action posts the card data straight to the processor. Your server never receives a card number, but the form came from you.
- JavaScript form. Your page loads script that collects the card number in the browser and sends it to the processor. The data path skips your server; the code that handles the number still came from your site.
Why does the line sit there? Because anything your site delivers, a change to your site can alter. If your website serves the form or the script, then the security of your website affects the security of the transaction, even though no card data flows through you. That is the exact concept behind SAQ A-EP eligibility: the merchant website can affect transaction security but does not itself receive cardholder data. With a full redirect or a provider-hosted iframe, the payment content originates from the processor’s systems instead, which is why those patterns stay on SAQ A.
One honest caution about names: providers market these integrations as “hosted checkout,” “embedded fields,” “drop-in,” and a dozen other things, and the label decides nothing. The mechanics do. Check your provider’s own PCI documentation for which SAQ your specific integration type maps to, and have your acquiring bank confirm it. If you sell through a platform, our guides for Shopify, WooCommerce, and Stripe walk through the common cases.
Two minutes tells you which side you’re on.
Answer a few questions about how your checkout actually works and the free check computes your likely SAQ on screen. No email to see the result, no card, nothing to install. It is indicative, not a QSA assessment, and it is the fastest way to know whether you are reading the right guide.
What else moves you out of SAQ A
The A-EP boundary is the famous one, but it is not the only exit. Watch for these:
- Storing cardholder data electronically. Anywhere in your environment, and the reduced SAQs are gone; SAQ D generally applies. This includes the places people forget: exports, application logs, call recordings, a spreadsheet someone keeps “just in case.”
- 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. Take cards more than one way and your environment can span more than one SAQ; your bank tells you how to validate the whole picture.
- Staff keying card numbers into your own systems. Phone orders typed into an isolated, third-party-hosted virtual terminal point to SAQ C-VT. Typed into anything you run, your CRM, your order admin, your database, and you are processing cardholder data yourself. SAQ A no longer describes you.
- An unvalidated provider in the chain. SAQ A leans entirely on the validation of your third parties. A provider that cannot show current PCI DSS validation breaks eligibility.
What you actually answer
SAQ question counts vary by PCI DSS version, so we will not quote one. The shape is what matters: a shorter SAQ covers fewer requirements, and SAQ A is the shortest because most of the 12 PCI DSS requirements sit with your providers rather than with you.
Expect the questions that remain to center on what is still in your hands: how you select and keep track of the validated third parties doing your card work, basic account and access hygiene for whatever still connects to your sales channel, how you protect any cardholder data that reaches you on paper, and whether your security policy actually exists in writing. The exact set depends on the version you validate against; the SAQ A 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. Whatever SAQ A looked like the last time you completed one, answer this year’s against the current requirement set. Our v4.0 deadlines guide has the full timeline.
When you finish, you sign the Attestation of Compliance and submit it to your acquiring bank or the card brands. That signature is you attesting, which is exactly why it is worth being certain SAQ A is truly yours before you get there.
How to confirm SAQ A 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. And a Qualified Security Assessor (QSA) can give you an assessor’s judgment when the boundary is genuinely unclear.
Before either conversation, it helps to walk in already knowing your likely answer and the reasons behind it. 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
Is an iframe checkout SAQ A or SAQ A-EP?
If the frame’s contents are hosted by your validated processor, so the payment form itself is delivered from the processor’s systems, that pattern points to SAQ A. If your own site serves a form or JavaScript that collects card data and sends it to the processor, that points to SAQ A-EP. Confirm your specific integration with your provider’s PCI documentation and your acquiring bank.
Does SAQ A apply to phone and mail orders?
Yes. SAQ A covers card-not-present acceptance, which includes mail order/telephone order (MOTO), when every cardholder-data function is fully outsourced to PCI DSS validated third parties. If your own staff key card numbers into systems you run, that is not fully outsourced, and SAQ A no longer fits.
My payment form posts card data directly to the processor. Is that SAQ A?
No. A direct-post or JavaScript form served from your website points to SAQ A-EP, even though the card data goes straight from the customer’s browser to the processor. Your site delivers the form or script, so your site can affect the security of the transaction. That is the SAQ A-EP definition.
Does qualifying for SAQ A mean PCI DSS barely applies to me?
SAQ A is the shortest questionnaire because you have outsourced the most, but it is still a real validation. You answer the requirements that remain yours, sign an Attestation of Compliance, and submit it to your acquiring bank or the card brands on the schedule your bank sets.
What disqualifies a merchant from SAQ A?
The common ones: storing cardholder data electronically anywhere you control, which generally moves you to SAQ D; serving the payment form or script from your own site, which points to SAQ A-EP; adding a card-present channel, which validates under other SAQ types; and using a third party that is not PCI DSS validated.
Who decides 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.