Explained to kids!
PCI DSS is the list of safety rules for anyone who takes card payments. A SAQ is the checklist a shop fills in once a year to show it follows them. The less a shop touches card secrets, the shorter its checklist. SAQ A is the short one. SAQ D is the long one.
Let’s see it in real life…
On Saturdays, Sofia helps her aunt Nadia at her flower stall at the market.
Today a man from the market office brings a big envelope: “Card safety checklist. Everyone who takes cards must fill it in.”
Aunt Nadia smiles. Her checklist is one page. Sofia asks why.
“When someone pays me by card, the card secret goes straight into the bank’s little reader. I never see it, I never write it down, I never keep it.”
“So you have less to promise?” “Exactly. I only promise to use the reader properly and to keep it safe.”
Next door, Mr. Baptiste at the bike shop has an envelope as thick as a book.
He takes orders by phone, writes card numbers on a notepad, and keeps the notepad in a drawer.
“If you keep the secrets, you must prove you protect them,” says the market man. “Locks, who has the key, what you do if the drawer is forced.”
Mr. Baptiste sighs and looks at the little reader on Aunt Nadia’s table.
“Maybe I should let the bank keep the secrets too.” “Then your envelope gets thin, like mine.”
Sofia counts the sunflowers. Aunt Nadia has already finished her page.
That is the difference between SAQ A and SAQ D.
Tiny recap
- It means… a shop fills in a checklist to show it keeps card secrets safe. Short if the bank keeps the secrets, long if the shop keeps them.
- It helps when… a shop lets a trusted helper handle the card secret, so there is less to protect and less to prove.
- Watch out for… a notepad with card numbers in a drawer. Keeping secrets you do not need is the fastest way to a very long checklist.
…detailed for specialists
PCI DSS SAQ A and SAQ D are two Self-Assessment Questionnaires under the PCI Data Security Standard. SAQ A is the short questionnaire for card-not-present merchants that fully outsource card data handling to a compliant provider. SAQ D is the full questionnaire for everyone else, including merchants whose own systems touch card data and most service providers.
In 2026 the choice matters more than it used to. PCI DSS v4.0.1 replaced v4.0 at the end of 2024, the SAQ A eligibility criteria changed on March 31, 2025, and script-based skimming of payment pages is now treated as a merchant problem, not only a provider problem. For a PSP, PayFac or platform, the SAQ each merchant qualifies for is set by the integration the platform offers.
What is a PCI DSS self-assessment questionnaire?
PCI DSS applies to every entity that stores, processes or transmits cardholder data. Large merchants and large service providers are assessed on site by a Qualified Security Assessor, who writes a Report on Compliance (ROC) and signs an Attestation of Compliance (AOC). Smaller entities validate themselves with an SAQ: a checklist of PCI DSS requirements, filtered down to the ones that apply to a given way of accepting cards, plus the same AOC. The SAQ types for v4.0.1 are A, A-EP, B, B-IP, C, C-VT, D for merchants, D for service providers, P2PE and SPoC, published in October 2024, with the v4.0 SAQs retired at the end of 2024. For online payments, three of them matter: A, A-EP and D.
SAQ A vs SAQ A-EP vs SAQ D: which one applies to which integration?
The PCI SSC’s SAQ Instructions and Guidelines (v4.0.1 r1, April 2025) draw the lines.
- SAQ A is for card-not-present merchants that “completely outsource all account data functions to PCI DSS validated and compliant third parties.” For e-commerce, every element of the payment page delivered to the browser must “originate only and directly from a PCI DSS compliant TPSP/payment processor.” In practice: a full redirect to a hosted payment page, or a provider-hosted iframe.
- SAQ A-EP is for e-commerce merchants that “partially outsource payment processing.” The merchant’s site “does not receive account data but controls how customers, or their account data, are redirected.” In practice: a direct post from the merchant’s own form to the provider, or a provider JavaScript that renders fields into a page the merchant controls. The PCI SSC explains the difference between redirect, iframe and direct post in its FAQ.
- SAQ D applies to “all merchants not included in descriptions for the above SAQ types.” If the merchant’s server receives a card number and forwards it by API, even without storing it, it is SAQ D. Mail and telephone orders typed into a merchant system usually land here too.
The gap between the three is large. After the 2025 update, SAQ A has 27 applicable requirements, against 151 for SAQ A-EP, and SAQ D runs to around 250. The test the assessors use is simple: can the merchant’s own code influence what happens on the payment page? If yes, SAQ A is out.
What changed in SAQ A on March 31, 2025?
PCI DSS v4.0 added two payment-page requirements to SAQ A, future-dated to March 31, 2025: 6.4.3 (inventory and authorization of every script on the payment page) and 11.6.1 (a change-and-tamper detection mechanism on the page). In January 2025 the PCI SSC published a revised SAQ A that removed 6.4.3 and 11.6.1, and 12.3.1 (the targeted risk analysis that supported 11.6.1), while stressing that “these requirements were only removed from SAQ A, and they are still in the standard.” The October 2024 SAQ A stayed valid until March 31, 2025, when the new version took over.
In exchange, SAQ A gained an eligibility criterion: the merchant must confirm that its site “is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” PCI SSC FAQ 1588 gives two routes to that confirmation: applying techniques such as those in 6.4.3 and 11.6.1, by the merchant or a third party, or obtaining confirmation from the compliant provider that supplies the embedded iframe, “when implemented according to the TPSP’s/payment processor’s instructions.” The criterion applies to pages that embed a provider’s form; it does not apply to a plain redirect. Two things did not change: SAQ A still requires quarterly external vulnerability scans by an Approved Scanning Vendor, even for redirect and iframe merchants, and a merchant that cannot make the confirmation moves to SAQ A-EP.
The practical effect for 2026: an iframe integration is still SAQ A, but the merchant now depends on a written statement from its PSP or platform, and the PSP needs to be able to give one.
What about service providers: ROC, AOC and the registries?
A PSP, PayFac or white-label platform that handles card data for merchants is a service provider, with its own validation. Visa sets Level 1 at more than 300,000 Visa transactions a year, with an annual on-site assessment by a QSA, an AOC signed by both, and quarterly ASV scans; Level 2 providers submit an annual SAQ D for service providers. Visa also requires that issuers and acquirers ensure all their service providers demonstrate PCI DSS compliance at least every 12 months, and lists validated providers on its Global Registry of Service Providers. That AOC is the document a merchant needs to tick the SAQ A box “the merchant has confirmed that TPSP(s) are PCI DSS compliant for the services being used.”
PCI DSS SAQ in numbers (2026)
- Checklist size: 27 requirements for SAQ A, 151 for SAQ A-EP since the January 2025 revision.
- Deadline: the v4.0 future-dated requirements became mandatory on March 31, 2025, one year after v4.0 took effect.
- Clarification: FAQ 1588 on the new SAQ A criterion was published on February 28, 2025, for criteria taking effect on April 1, 2025.
- Service provider level: 300,000 Visa transactions a year is the line between Level 2 (SAQ D) and Level 1 (on-site assessment).
- Why it matters: Verizon’s 2025 DBIR found that third-party involvement in breaches doubled to 30%, across 12,195 confirmed breaches.
How does a white-label platform reduce PCI scope?
Scope is decided by where card data travels. A platform that serves hosted payment pages and hosted fields from its own PCI DSS validated infrastructure keeps card data out of the merchant’s systems and out of the PSP’s brand-level systems too. The merchant qualifies for SAQ A, the operator presents the platform’s AOC to its acquirers, and the responsibility matrix between the three parties can be written down. Card data stored for recurring payments stays in the platform’s vault, replaced by tokens, which also keeps the merchant’s subscription database out of scope. The remaining merchant duties, ASV scans, the script confirmation and the AOC collection, are small enough to automate at onboarding. We covered the standard in PCI DSS 4.0 and the operator view in PCI DSS v4.0 for PayFacs.
PCI DSS SAQ: what changes for PSPs, PayFacs and platforms
Onboarding: collect the right SAQ for each merchant
Acquirers hold PayFacs and PSPs responsible for the compliance of their sub-merchants. The onboarding file should record which integration each merchant uses, derive the SAQ type from it, and collect the signed AOC with its expiry date. A merchant on a hosted page gets SAQ A; a merchant that built its own form with the platform’s JavaScript gets SAQ A-EP, and should know it before it signs.
Integration choice is a compliance decision
Offering only a redirect or a fully provider-served iframe keeps every merchant in SAQ A. Offering direct API access moves the merchant to SAQ D and the operator into a longer conversation with its acquirer. The common pitfalls are old but still current: logging card numbers in support tools, keeping PANs in exports, or accepting card details by email.
Compliance evidence has to be ready on demand
Since 2025, merchants on an iframe need the provider’s written confirmation about script protection, acquirers ask for the provider’s AOC at least yearly, and schemes keep a registry. Operators that run several brands or several acquirers through payment orchestration need one place where the AOC, the ASV scan reports and the responsibility matrix live, and a calendar that fires before any of them expires. A trust center is the public face of that file; the acquirers and PSPs connected behind the platform each need their copy.
Fraud controls stay outside the SAQ
A short SAQ does not stop card testing on a hosted page. Velocity limits, CAPTCHA on card entry and BIN checks belong to the platform, whatever questionnaire the merchant signs.
NORBr runs its hosted pages, vault and operations on infrastructure covered by Platform Operations & Security, so operators and their merchants inherit the scope reduction under their own brand.
Is SAQ A worth it in 2026?
Yes, and it is still the cheapest path for a merchant, at 27 requirements instead of 151 or 250. The 2025 change moved the burden rather than removing it: the merchant now relies on its provider’s script protection and written confirmation, and still owes quarterly ASV scans and a yearly AOC. For PSPs, PayFacs and platforms, the lesson is to decide scope at integration design time, to collect the right SAQ at onboarding, and to keep the provider-side evidence ready for every acquirer. A platform that does the heavy part once, under the build-or-buy arithmetic, is what makes SAQ A available to every merchant in the portfolio. For a running view of the compliance side, Willem Wellinghoff’s notes on payments and compliance in our library are a good companion.
Frequently Asked Questions
What is the difference between SAQ A and SAQ D?
SAQ A is the short PCI DSS questionnaire for card-not-present merchants that fully outsource card data handling to a compliant provider, with 27 requirements since 2025. SAQ D is the full questionnaire for everyone else, around 250 requirements, including merchants whose servers receive card numbers and most service providers.
Which PCI SAQ applies to an iframe or redirect integration?
A full redirect to a hosted payment page or a provider-hosted iframe qualifies for SAQ A. A direct post from the merchant’s own form, or provider JavaScript rendering fields into a merchant-controlled page, requires SAQ A-EP. If the merchant’s server touches the card number, it is SAQ D.
What changed in PCI DSS SAQ A in 2025?
On March 31, 2025, requirements 6.4.3, 11.6.1 and 12.3.1 were removed from SAQ A and replaced by an eligibility criterion: the merchant must confirm its site is not susceptible to script attacks, either through its own controls or a written confirmation from the provider supplying the iframe. ASV scans still apply.
Do SAQ A merchants need vulnerability scans?
Yes. The PCI SSC confirms that SAQ A for PCI DSS v4.x includes quarterly external vulnerability scanning by an Approved Scanning Vendor, including for merchants whose pages redirect to a provider or embed its iframe. The merchant remains responsible for the requirements listed in SAQ A.
How does a PayFac prove PCI compliance for its merchants?
The PayFac validates itself as a service provider, with an annual ROC and AOC by a QSA above 300,000 Visa transactions a year, and collects each sub-merchant’s SAQ and AOC at onboarding. Using hosted pages and a tokenized vault keeps merchants in SAQ A; hosted checkout pages are the usual tool.
