What SAQ A Eligibility Means
A merchant may use PCI DSS Self-Assessment Questionnaire A, or SAQ A, only when nearly all payment-card handling is performed by a PCI DSS-compliant service provider and the merchant itself does not electronically store, process, or transmit sensitive authentication data during payment. The merchant may still retain payment-page responsibility, determine whether the outsourced arrangement qualifies, review evidence, and complete its annual attestation. SAQ A is therefore not a general exemption for small merchants, nor is it automatically available to every merchant that uses a payment gateway or payment link. A low-volume or small merchant must meet the same underlying eligibility conditions as any other organization relying on this reduced assessment.
Also worth reading: What Is the Best Practical Guide to Digital Payments for Wallets, Transfers, and Merchant Checkout? · What Is Merchant Payment Orchestration and When Is It Worth the Cost? · How Much Can Stablecoin Merchant Fees Really Be Reduced in 2026?
Sensitive authentication data normally consists of the cardholder’s full primary account number, card verification code or value, and expiration date when all three are captured. Account data can be retained, but only in a form the merchant is permitted to keep, such as truncated or tokenized data. The arrangement also depends on the provider being an eligible PCI DSS service provider, the provider covering the systems that handle the merchant’s card data, and a written agreement clearly allocating security responsibilities. If the merchant operates infrastructure that influences account-data security, it should not select SAQ A merely because no full card numbers are stored.
How SAQ A Differs from Other PCI DSS Reports
SAQ A is the shortest PCI DSS self-assessment available to qualifying merchants, but its short length does not make it a universal “easy” option. The central distinction is the location and control of payment functions. SAQ A assumes that eligible third parties perform the electronic storage, processing, and transmission of cardholder data. SAQ A-EP applies when a merchant’s website redirects buyers to a PCI DSS-compliant payment page, but that website can affect account-data security through scripts, payment-page content, or other technical conditions. SAQ D is used for service providers and generally requires a full report or qualified security assessment.
The questionnaire choice should be determined by architecture and responsibility, not by the wording used by a payment vendor. A hosted checkout, embedded form, application, payment link, customer wallet, and custom card reader can create different reporting obligations. The comparison below is therefore a practical starting point, not a substitute for reviewing the actual merchant environment and the current PCI SSC eligibility criteria.
| Feature | SAQ A | SAQ A-EP | SAQ D |
|---|---|---|---|
| Typical user | Merchant outsourcing nearly all card-data functions | Merchant whose site affects outsourced payment security | Service provider |
| Electronic card-data handling | Outsourced to eligible providers | Outsourced, but merchant site influences security | Provider handles cardholder data or systems supporting it |
| Typical validation | Self-assessment plus supporting documentation | Self-assessment plus expanded security requirements | Full PCI DSS report or QSA assessment |
| Main decision question | Does the merchant itself never electronically store, process, or transmit sensitive authentication data? | Could the merchant’s site change or compromise payment-page security? | Is the organization operating systems that store, process, or transmit card data? |
PCI DSS version 4.0.1 did not create a new SAQ A eligibility category simply because a merchant uses a gateway. Instead, it clarified how merchants must address risks that exist outside the provider’s cardholder-data environment. Changes became effective on 31 March 2025 and introduced or revised requirements dealing with payment-page scripts, changes to payment pages, browser-skill attacks, and related security controls. For merchants using iframe or redirect methods, SAQ A v4.0.1 includes requirements intended to reduce the chance that unauthorized scripts capture or modify payment information.
These requirements matter because an outsourced data path does not necessarily mean an entirely untrusted merchant web environment. A compromised browser, malicious script, altered payment page, or inadequate change-detection process can undermine security even when the actual card-data database belongs to a service provider. The merchant does not gain SAQ A eligibility simply by outsourcing data storage. It must still satisfy the questions and supporting controls stated in the current questionnaire, and an acquirer or assessor may ask for evidence showing that the provider and the deployment are covered.
The phrase “eligible service provider” is also more specific than “a payment company.” A provider that processes cards for merchants is not automatically eligible in every PCI DSS service-provider scope, and outsourcing to a company does not erase the responsibility to verify contractual terms and the provider’s compliance status. Organizations should obtain a current PCI DSS Attestation of Compliance or AOC, confirm that the service is on the payment-data path they use, and check whether the provider’s assessment covers the relevant platform and services. Payment brands and acquirers can impose additional expectations even when the PCI SSC questionnaire appears to permit a reduced scope.
A Practical Eligibility Review
Start with a written map of every system that creates, routes, captures, stores, processes, or transmits cardholder data. Include hosted checkout pages, embedded fields, iframes, redirects, mobile applications, call-center recordings, customer-service tools, spreadsheets, CRM systems, loyalty programs, and any system capable of receiving full card details. Do not rely only on diagrams supplied by the payment processor. The review must distinguish actual data custody from systems that merely display non-sensitive information or create a payment session.
Next, inspect the integration used for each payment method. A hosted checkout on a provider-controlled domain may support SAQ A, while a JavaScript form embedded directly into the merchant site can change the classification. Payment links that redirect the customer to a compliant provider usually operate differently from methods that transmit card data through the merchant’s server. A terminal supplied by a provider is not the same as a point-of-sale integration that sends raw card data to an application controlled by the merchant. Record who controls each domain, server, API, SDK, and data store, because “the processor handles it” is too vague to support an eligibility decision.
The review should then verify contracts, AOC coverage, incident responsibilities, and any prohibited retention. Agreements should identify the provider’s PCI DSS status, the covered services, incident-notification duties, deletion or return of data, subcontractor issues, and the merchant’s responsibilities for the site or application it controls. The merchant should not accept an outdated AOC or a statement that is unrelated to the actual service. It also should not infer that SAQ A permits storage of full card numbers “for convenience” after authorization.
What Merchants Must Do After Choosing SAQ A
A merchant that qualifies should complete every requirement in the current SAQ A and submit it through the process required by its acquirer or payment brands. PCI SSC questionnaires are attestation tools, not certification badges. A merchant still needs supporting evidence for the responses it submits, and a completed SAQ does not prove that its payment provider is compliant. The questionnaire is usually renewed annually, while PCI DSS v4.x requirements became effective on 31 March 2025, so merchants should use the version requested by their acquirer rather than searching for an older form online.
Payment-page security deserves particular attention in 4.0.1. Depending on the applicable requirements and implementation, the merchant may need a documented method for confirming that scripts loaded on the payment page are authorized, integrity-checked, and inventoried. It may also need change-detection or tamper-detection capability, defined responsibilities for reviewing payment-page changes, and a process for responding to unauthorized scripts. These controls do not mean that every merchant must install the same expensive software product. A well-designed managed solution, tightly controlled deployment process, and documented review can satisfy a requirement when they meet the stated objective and the assessor accepts the evidence.
The merchant should also protect the administrative side of compliance. Access to the acquirer portal, AOC records, script inventories, domain controls, and change-approval records should be restricted to authorized personnel. A dormant employee account or an unrestricted content-management role can weaken the same environment that the questionnaire addresses. Evidence should be retained in a form another responsible person can locate and reproduce six months later, because a correct answer without documentation is unlikely to survive review.
Common Reasons a Merchant Loses SAQ A Eligibility
One common mistake is equating “we do not store cards” with “we do not process or transmit cards.” A server-side application that receives a PAN and immediately forwards it to a gateway has electronically processed or transmitted cardholder data, even if it writes nothing to disk. Another mistake is treating browser forms as harmless. An embedded form can expose sensitive data to a compromised browser or merchant-controlled script, and the correct assessment may be SAQ A-EP rather than SAQ A.
Other errors include relying on a provider’s PCI logo, failing to confirm that the AOC covers the contracted service, or assuming that a subcontractor is automatically covered. Merchants also misclassify systems by looking only at persistent storage. Memory, logs, network traffic, APIs, screenshots, recorded sessions, and temporary files can all matter depending on what they contain and how they are controlled. A merchant that allows full card numbers to enter a customer-service or accounting workflow may have created its own in-scope system even when the original payment was completed through a hosted page.
Changes over time can invalidate an old eligibility decision. A redesigned checkout, new JavaScript SDK, mobile application, fraud-screening service, or cloud integration may alter who can affect payment data. Merchants should re-evaluate whenever payment methods, domains, service providers, data flows, or material site functionality change. The answer should not be a one-time label attached permanently to an account.
Cost, Timing, and Merchant Versus Service-Provider Duties
SAQ A itself generally has no separate PCI SSC questionnaire fee, but the total cost is not necessarily zero. The likely costs include payment-provider fees, compliance software, managed security monitoring, developer or operations time, legal and contractual review, QSA assistance, and any assessment required by the acquirer. A simple redirect or host-controlled checkout may need modest administrative effort, while a custom embedded implementation can require substantial testing and monitoring. The appropriate comparison is full environmental cost, not merely the number of pages in the questionnaire.
There is no universal SAQ A price because the PCI SSC provides the questionnaire, while validation and assessment obligations come through the payment ecosystem. Acquirers can require additional documentation, and the applicable validation path can depend on how the merchant acquired services and how payment brands classify its organization. Merchants should obtain written confirmation from the acquirer about the required questionnaire, submission deadline, and any supporting evidence. Payment providers may supply a compliance package, but that package should not be confused with legal, contractual, or technical verification.
A service provider and a merchant can share duties, but they do not become one reporting entity. The service provider typically protects its cardholder-data environment and supplies a current AOC. The merchant remains responsible for its own eligibility, site controls, contracts, access management, and accurate answers. If a merchant stores or processes card data itself, outsourcing does not transfer that control. In that situation, it should discuss a broader PCI DSS assessment path with its acquirer rather than attempting to fit the arrangement into SAQ A.
When to Reassess and Seek Help
A merchant should reassess before adding a new payment method, moving a checkout onto a new domain, replacing a gateway, launching a mobile app, or changing the scripts that interact with payment pages. It should also review eligibility after a provider is acquired, after a material security incident, or whenever a processor’s AOC is unavailable or does not clearly cover the service. Small volume is not a reason to wait, because reduced assessment scope is based on the data path and organizational role rather than annual transaction revenue alone.
A qualified security assessor can help resolve architectural questions, and the acquirer should confirm the reporting channel. The assessor cannot declare a merchant eligible without examining the actual implementation, and the acquirer may have its own onboarding rules. If a company is uncertain whether a hosted payment page, embedded field, or tokenization service qualifies, the safer course is to pause the change until the data flow is documented. Spending time on a compliant design is generally more economical than completing a questionnaire that later proves inapplicable.
As of 25 September 2026, the practical message is stable: SAQ A remains available for qualifying merchants, but payment-page controls and provider verification are no longer details to ignore. Merchants should use the current PCI DSS v4.0.1 questionnaire requested by their acquirer, preserve evidence, and recheck the arrangement whenever the checkout changes. The most defensible SAQ A claim is not “our gateway takes care of PCI”; it is “we have verified the architecture, current provider status, contractual responsibilities, and controls that keep account data protected.”