SAQ-A vs SAQ-D: what it costs and how to lower it

SAQ-A vs SAQ-D: the short version

When people compare SAQ-A vs SAQ-D, they are really comparing two amounts of work that follow from one question: does a real card number ever enter your systems? SAQ-A is the short questionnaire for merchants who fully outsource card handling. SAQ-D is the long one for everyone who stores, processes, or transmits cardholder data themselves.

Both are Self-Assessment Questionnaires under PCI DSS. The letters do not rank how secure you are. They describe how your environment handles card data, and that shapes how much you have to attest to.

What each questionnaire requires

SAQ-A is built for card-not-present merchants who have handed off all cardholder data capture to a compliant third party, typically through a redirect or hosted fields on the provider's domain. It focuses on a small set of controls: you still manage your own accounts, keep the provider relationship documented, and make sure nothing on your side reintroduces card data.

SAQ-D is comprehensive. It walks through all twelve PCI DSS requirements in detail: network security, protecting stored data, encryption in transit, malware defense, access control, authentication, physical security, logging, testing, and policy. Where SAQ-A assumes you hold nothing sensitive, SAQ-D assumes you hold a lot, and asks you to prove each protection.

What does SAQ-D cost that SAQ-A does not?

The cost difference shows up in three places: time, evidence, and ongoing operations. SAQ-A can often be completed by a small team in a short sitting, because most questions do not apply. SAQ-D can take weeks, because you are gathering evidence for encryption, key management, and log retention, and often coordinating across engineering, IT, and security.

There is also a recurring cost. SAQ-D controls have to keep running, and many organizations bring in outside help or tooling to maintain them. SAQ-A carries far less of that overhead. None of this is a fixed dollar figure, since it depends on your systems, but the direction is consistent: SAQ-D is materially heavier every single year.

How to move from SAQ-D to SAQ-A

Moving from SAQ-D to SAQ-A is an architecture change, not a paperwork trick. The goal is to remove card data from your environment entirely. In practice that means capturing cards through hosted fields served from a compliant provider's domain, replacing any stored card numbers with tokens, and removing any code path where your servers see the raw number.

Once no system of yours can touch a card number, you may become eligible for SAQ-A. The work is front-loaded into the integration, and then your annual assessment gets dramatically smaller.

A caution about eligibility

Eligibility is specific, and it is yours to determine, often with a Qualified Security Assessor or your acquiring bank. Using a compliant provider does not automatically grant SAQ-A if, for example, your page still collects the card and forwards it, or if you host the payment script yourself in a way that puts your servers in the path.

The questionnaire you qualify for depends on the details of your integration, not the logo of your processor. It pays to confirm the specifics before you assume the shorter path is open to you.

How Flux helps you qualify for the shorter path

Flux is designed for the SAQ-A path. Card data is captured inside origin-isolated iframes on payments.fluxpayments.com, so it never reaches your servers or domain, and Flux tokenizes the card so saved-card and recurring flows work without storage on your side. Flux itself is SAQ-D Level 2 PCI DSS certified on the infrastructure that receives the data.

Your job becomes integrating the fields correctly and securing your own accounts and systems. Done that way, the comparison between SAQ-A and SAQ-D stops being a question of effort and becomes a question of design you have already settled.