PCI SAQ A: who qualifies and how to file it

SAQ A is Self-Assessment Questionnaire A, the PCI DSS form for merchants that take cards only online, by mail or by phone and leave every part of card handling to a PCI DSS compliant provider. If customers type their card details on your provider's hosted payment page, or into card fields the provider serves inside your checkout, and nothing on your own systems stores, processes or transmits those details, SAQ A is probably the questionnaire your acquirer expects. It's the lightest PCI paperwork there is, and it holds only while every one of its conditions does.

We'll cover who qualifies, the 2025 change for online stores, the checkouts that fit and the ones that don't, and what filing takes. Rules are as of October 2026. For the standard as a whole, start with what PCI compliance is.

What is SAQ A in PCI DSS?

SAQ A is one of the self-assessment questionnaires the PCI Security Standards Council (PCI SSC) publishes so merchants can check their own setup against PCI DSS and report the result. The Council says each of those questionnaires was created to support a specific type of environment. SAQ A's environment is the narrowest one: card-not-present sales where a third party does all of the card handling and the merchant does none.

That narrowness rules some businesses out from the start. PCI SSC's SAQ A for PCI DSS v4.0.1 says the questionnaire isn't applicable to face-to-face channels, and service providers can't use it either. A boutique with a countertop terminal and a web store needs more than SAQ A for the counter, so ask your acquirer how it wants the two channels reported.

The Council also writes the questionnaire without deciding who has to file it. Its About Us page leaves that to the payment brands and acquirers that run compliance programs. In practice the request comes from your acquirer, the bank behind your merchant account, and Visa requires acquirers to obtain the required compliance validation documentation from their merchants.

Who qualifies for SAQ A?

You qualify when every statement below is true for your business. These are our plain-English versions of the eligibility criteria in PCI SSC's current SAQ A, its 2025 update for e-commerce merchants and its FAQ 1292 on payment pages:

1. You accept only card-not-present transactions: e-commerce, mail order or telephone order.
2. All card data processing is fully outsourced to a PCI DSS compliant third-party service provider.
3. Nothing on your own systems or premises stores, processes or transmits card data electronically.
4. You've confirmed that each provider is PCI DSS compliant for the services you use.
5. Any card data you keep is on paper, and none of it reached you electronically.
6. Online, every element of the payment page that reaches a shopper's browser comes directly from a PCI DSS validated provider. If any part of it originates from your website, FAQ 1292 says the setup isn't eligible.
7. Online, you've confirmed your site isn't susceptible to attacks from scripts that could affect your e-commerce systems.

Read item 3 the strict way. A card number sitting in a staff inbox, a chat log or a spreadsheet is stored electronically, and it also arrived electronically, which breaks item 5 too. One forwarded email can cost you the shortest form.

Take a made-up online tea shop in Portland. Shoppers click Pay, land on the processor's hosted page and come back to an order confirmation. The shop's system receives an approval and an order number, never a card number. Items 1 to 6 hold. Item 7 is aimed at embedded payment forms, and the shop redirects, so PCI SSC's FAQ on the change says the script check doesn't apply. SAQ A fits.

Then a wholesale buyer emails a card number for a bulk order, and someone types it into the processor's portal from the shop's laptop. The card data arrived by email and was keyed on the shop's own computer. From that day, SAQ A no longer describes the business.

What changed in SAQ A in 2025?

Three requirements came out of SAQ A, and one eligibility check went in. PCI SSC's announcement lists the removals: Requirements 6.4.3 and 11.6.1, the two payment page security requirements, and Requirement 12.3.1, the targeted risk analysis that supported 11.6.1. In their place, merchants confirm that their site isn't susceptible to attacks from scripts that could affect their e-commerce systems. Merchants filing SAQ A have had to make that confirmation since March 31, 2025.

PCI SSC then explained who the new check is for. Its FAQ 1588 says the criterion covers sites that embed a payment form, the iframe setup, and not sites that redirect shoppers or send payment links by email. It also gives two ways to meet it: script protections you run on your own site, or your provider's confirmation that its embedded form includes them.

Our view: if your provider will put that confirmation in writing, an embedded checkout stays almost as light as a redirect. If it won't, you're the one running and documenting script protections, and the redirect starts to look like the better deal.

Which checkouts usually fit SAQ A?

The ones where the provider serves every part of the payment page. That means a redirect to a hosted payment page, provider-served card fields inside your checkout, or a payment link. FAQ 1292 accepts both redirects and iframes, as long as every element of the payment page comes from the provider. Our hosted payment page guide compares those designs, and the table below adds the setups that land somewhere else.

Sources: PCI SSC's FAQ 1292, the v4.0.1 SAQ A-EP and SAQ C-VT forms, and the v4.0.1 SAQ D for merchants.

Mail and phone orders can qualify too, since SAQ A's first eligibility item names them. Items 2 and 3 are the catch: once someone in your office types a card number into a computer, a different questionnaire usually applies.

Still deciding how to sell online? Our guide on how to accept payments online compares the options, and our ecommerce merchant account guide explains the account behind them.

What pushes a merchant from SAQ A to SAQ A-EP or SAQ D?

Usually a change nobody treated as a PCI decision: a redesign, a new sales channel or a shortcut taken to rescue one sale. These are the common triggers, and where each one tends to land:

1. A custom payment form. If a developer rebuilds the card form on your own site, part of the payment page now originates from your website, which FAQ 1292 says ends SAQ A eligibility. A form that posts card data straight to the gateway is the setup SAQ A-EP was written for.
2. Card data through your server. Calling the gateway from your own back end, or saving cards in your own database, puts card data on your systems. That's SAQ D territory.
3. Card numbers by email, text or chat. Accepting one "just this once" means card data was received electronically, and keeping it means it's stored. Send a payment link instead.
4. A card reader at a market stall or a counter. SAQ A doesn't cover face-to-face sales, so the new channel brings its own questionnaire.
5. A provider you can't vouch for. The criteria need your confirmation that each provider is PCI DSS compliant for the services you use, so ask for its Attestation of Compliance before you sign.
6. An embedded form with no script protection on record. Since the 2025 revision, that fails the eligibility check even when everything else is in order.

Landing in A-EP or D means more than a longer form. SAQ A-EP is for e-commerce merchants that only partially outsource their payment channel, as the Council's v4.0 form describes them, so your own website's security becomes part of what you attest to. SAQ D is the catch-all, written for setups that none of the shorter forms describe.

An example, with made-up details: a print shop in Salt Lake City sells business cards through a hosted checkout and files SAQ A. To speed up reorders, a developer adds an admin screen where staff type a returning customer's card, and the shop's server forwards it to the gateway. Shoppers see no change, but card data now flows through the shop's server, and SAQ D is the likely result. The provider's saved-card tokens, explained in our payment tokenization guide, or a payment link texted to the customer would have handled reorders without the card number touching the shop's systems.

Do SAQ A merchants need ASV scans?

Yes. For PCI DSS v4.x, PCI SSC added external vulnerability scans by an Approved Scanning Vendor (ASV) to SAQ A, and its resource guide on scans notes that SAQ A merchants are now meeting the scan requirement for the first time. For them, the scans cover the e-commerce systems that host the redirect or the embedded payment page, not the provider's systems.

The requirement behind it is 11.3.2, which calls for passing external scans by an ASV at least once every three months. PCI SSC's summary of the v4 questionnaires puts the SAQ A scan on merchant websites that redirect to a third-party provider or embed its payment page or form.

So book a scan of your storefront every quarter, fix what fails, rescan and keep each passing report. Our ASV scan guide covers what fails and how to dispute a false positive.

What does filing SAQ A involve?

Usually three documents: the questionnaire, the Attestation of Compliance that goes with it, and your passing scan reports. PCI SSC's version 3 questionnaire templates spelled out the delivery step: submit the SAQ and the Attestation of Compliance, with any other requested documentation such as ASV scan reports, to your acquirer, payment brand or other requester (PCI SSC). For most small online stores, the requester is the acquirer, and the request arrives through the processor.

The yearly routine looks like this:

1. Ask your acquirer which questionnaire it expects and how to submit it. PCI SSC's merchant page directs questions about compliance validation and reporting to the acquirer or the payment brands.
2. Walk through the seven eligibility statements above for every card-not-present channel you run.
3. Confirm each provider is PCI DSS compliant for the services you use. Asking for its own Attestation of Compliance is the simplest way.
4. If you embed the provider's fields, file its script-protection confirmation, or document the protections you run yourself.
5. Keep up the quarterly ASV scans for the site that redirects or embeds.
6. Answer the questionnaire honestly, then complete and sign the Attestation of Compliance.
7. Submit everything the way your acquirer asks, and keep copies.
8. Put next year's date on the calendar. Visa expects its Level 2 and Level 3 merchants to complete an SAQ every year (Visa).

Size only changes the form at the very top. Visa's Level 1, for merchants with over 6 million Visa transactions a year, files a Report on Compliance from a Qualified Security Assessor instead of a self-assessment. Our guide to PCI compliance levels lists each card brand's thresholds.

And if you don't file? When a processor charges a PCI non-compliance fee, it keeps showing up until your validation arrives. Our PCI compliance fee guide explains how to tell a fair program fee from a penalty. A breach costs far more; see what skipping PCI validation can cost.

SAQ A checklist: what to keep on file

Keep these together, and next year's filing takes an afternoon instead of a week:

• Your provider's Attestation of Compliance, or other proof it's PCI DSS compliant for the services you use
• The provider's written confirmation of script protection, if your checkout embeds its fields
• Each quarter's passing ASV scan report for your storefront
• Your signed SAQ A and Attestation of Compliance, with the date you submitted them
• A one-page list of every way you take card-not-present payments, and who handles the card data in each
• A note of when you last searched inboxes and shared drives for stray card numbers, and what you deleted

When isn't SAQ A worth building around?

For most small online sellers, SAQ A is the right target, and the checkouts that qualify are the easy ones to set up. It isn't the right goal for everyone:

• You sell mostly in person. SAQ A only ever covers your card-not-present side, so the terminal at your counter decides most of your PCI work.
• Your checkout's design measurably moves sales, and you have developers. Some businesses decide that full control of their own form is worth SAQ A-EP's extra work. That's a fair trade when it's made on purpose rather than by accident.
• You bill subscriptions. Don't store cards yourself to make that work; your provider's tokens let you charge returning customers without the card number ever reaching your systems.

If you want a checkout that keeps card data off your systems, our online payments cover hosted checkout and gateway integration, and orders can be screened with AVS, CVV checks and velocity rules. Our page for ecommerce businesses covers the rest of an online store's setup.

Your next step

Not sure your checkout still fits SAQ A, or paying a PCI fee you can't trace to anything? Send us a recent statement for a free statement review, and we'll mark every compliance-related charge and tell you which questionnaire your setup points to. Clearo offers PCI compliance support too, so if you'd rather walk through your checkout with a person, contact us.