The Direct Answer for E-Commerce Merchants
For a merchant accepting card payments through an online store, the usual starting point is PCI DSS SAQ D, but the correct self-assessment depends on the merchant’s payment channel. SAQ D applies when cardholder data is stored, processed, or transmitted through the merchant’s website or other internet-connected systems. A merchant using an embedded, iframe-based hosted payment page from a PCI-compliant payment service provider may qualify for SAQ A instead. Eligibility is not optional, however: the merchant must satisfy every condition in the current SAQ, and an acquirer or payment brand must confirm the classification where practical.
Also worth reading: How do I build secure merchant checkout workflows that handle modern agentic commerce and payment standards in 2026? · Which merchant payment gateway should a small business choose in 2026? · SAQ A Eligibility Checklist for PCI DSS 2026: Which Validation Type Fits Your Merchant?
As of 26 September 2026, merchants should use the current PCI DSS v4.x materials rather than deciding from an old questionnaire that was valid for an earlier PCI DSS version. PCI DSS v4.0 introduced technical and procedural changes, and v4.0.1 remains the principal version of reference for current compliance programs. The answer is not simply “choose the questionnaire with the fewest questions,” nor does using a marketplace such as Shopify or a payment processor automatically reduce the merchant’s obligations. The decisive issue is how account data enters the merchant’s environment and how the merchant’s web configuration is validated.
| Feature | SAQ A | SAQ D |
|---|---|---|
| Typical e-commerce use | Eligible hosted, redirect, or qualifying embedded payment page | Merchant website handles, processes, or transmits card data |
| Number of requirements | 22 in PCI DSS v4.x, subject to the current SAQ | 330 in PCI DSS v4.x, subject to the current SAQ |
| E-commerce security controls | Restricted to eligible outsourced payment-page arrangements | Broad merchant web-environment controls |
| Annual validation | Quarterly ASV scans for applicable SAQ A merchants | Quarterly ASV scans plus annual SAQ, penetration test, and applicable Segregation of Duties testing |
How PCI DSS SAQ Selection Actually Works
A Self-Assessment Questionnaire is a reduced set of PCI DSS controls tailored to a particular type of merchant or service provider. Merchants use it to demonstrate compliance to their acquiring bank, which in turn manages the relationship with Visa, Mastercard, American Express, or Discover. The payment brand sets the technical rules, but the acquirer often supplies the exact assessment process, deadlines, evidence requirements, and approved assessors. Consequently, two merchants with apparently identical checkout designs can receive different documentation requests from different acquirers.
Selection starts with tracing card data. The merchant should identify whether the number, expiration date, card verification code, or full track data is stored, processed, or transmitted by the merchant-controlled system. It should also identify whether card data is entered into a page, frame, redirect, browser session, application server, API, plugin, downloadable mobile application, or third-party marketplace. Merchants often focus only on their checkout page, while missing a hosted card-on-file form, customer-service tool, invoice workflow, fraud screen, logging service, or old integration. A single unapproved path can invalidate an otherwise persuasive claim of SAQ A eligibility.
The merchant then compares that architecture with the current SAQ eligibility rules and the “Payment Page Security and Prevention” section included for e-commerce merchants. Merchants must not treat a provider’s PCI compliance statement as proof that every merchant configuration is compliant. PCI DSS assigns responsibilities through contractual relationships, but it does not transfer the merchant’s legal or contractual duty to select an accurate questionnaire, protect its own environment, monitor third parties, or report incidents. A compliant processor reduces a merchant’s scope only when the integration actually matches the permitted architecture.
Hosted Payment Pages, Redirects, and Embedded Options
A redirect payment page is commonly the clearest SAQ A arrangement for many small e-commerce projects because card data is entered directly on the payment provider’s domain rather than the merchant’s site. The merchant receives only a payment result or token. This does not make the merchant’s website automatically free from security obligations, however. The redirect service, browser behavior, return URL, account creation, and merchant server must conform to the relevant eligibility controls. A website may still be exposed to credential attacks, order manipulation, account takeover, and insecure merchant-side processing even if raw card numbers never touch its server.
Direct or embedded card capture generally points toward SAQ D. An iframe is not a universal exemption, and the current standard contains a specific eligibility mechanism for qualifying embedded scripts. To use it, the payment page must meet requirements concerning page origin, framing boundaries, script loading, and the merchant’s control over the page. Merchants need current written confirmation from the payment provider that the chosen script and integration are supported. Simply seeing an iframe on checkout, receiving a “PCI compliant” badge, or relying on a provider marketing page is insufficient evidence.
| Architecture | Likely SAQ direction | Main compliance risk |
|---|---|---|
| Hosted page entered on provider domain | SAQ A may be possible | Redirect tampering, merchant account takeover |
| Hosted payment page through qualifying embedded script | SAQ A may be possible, but only under strict conditions | Incorrect script version, CSP or framing weakness, provider confirmation |
| JavaScript or iframe sends card data through merchant systems | SAQ D is commonly required | Exposure of merchant web servers and application logic |
| Marketplace-hosted checkout | Provider-managed processing may reduce merchant scope | Marketplace access rules, fraud, identity, and integration dependencies |
| Stored card data on merchant servers | SAQ D or a stricter validated path | Database security, encryption, retention, and breach impact |
The Practical Steps to Make the Decision
The first practical step is to inventory every place payment information travels. This should include desktop and mobile checkout, card-on-file payments, refunds, subscriptions, customer dashboards, call-center procedures, fulfillment tools, analytics scripts, and legacy systems. The review should distinguish data merely displayed from data captured, transmitted, processed, stored, or imported. Merchants should also check whether sensitive authentication data appears after authorization or whether the full magnetic-stripe track or card verification value is retained. Prohibited storage can create obligations beyond the questionnaire that was originally selected.
The second step is to obtain current written documents from the acquirer, processor, gateway, marketplace, and any software vendor that materially handles the flow. Useful evidence includes the PCI DSS Attestation of Compliance, responsibility matrix, service description, integration requirements, and confirmation that the proposed hosted or embedded method is eligible for the lower-scope SAQ. Documents expire, and a current vendor attestation does not prove that a merchant has implemented the recommended integration. Vendors should be asked for the exact product and service version, expiration date, supported countries, and any contractual restrictions.
The third step is to map the chosen SAQ to actual evidence rather than treating form completion as the whole project. SAQ A has 22 requirements in the current v4.x formulation, while SAQ D has 330. Even SAQ A is not “no work”: eligible merchants still address requirements such as secure configurations where applicable, strong authentication for administrative access, risk analysis, incident response, and quarterly scanning. SAQ D requires substantially broader evidence, including quarterly external vulnerability scans, an annual internal or external penetration test, and a Segregation of Duties test for applicable systems. The merchant should agree with its acquirer on scan and assessment dates before relying on stale reports.
The fourth step is to document the decision and revisit it after changes. Switching gateways, changing hosted-page providers, altering iframe code, introducing a saved-card workflow, or adding a marketplace can affect eligibility. Merchants should assign an owner for quarterly scans, annual assessments, provider reviews, and incident escalation. They should also ensure that their responsibility matrix matches the real technical architecture. This is especially important when vendors make sweeping claims about “out-of-scope” systems without explaining the merchant-side conditions attached to that treatment.
Costs, Timing, and the Difference Between SAQ Scope and Fees
A completed SAQ itself normally has no public PCI fee; the principal cost is labor and any compliance work required by the acquirer. An SAQ A can therefore be much less expensive than SAQ D for a small merchant because there are 22 requirements rather than 330 and fewer assessment methods apply. That difference does not guarantee a low overall security expense. Hosted checkout may add provider or processor fees, redirect and return handling costs, fraud screening charges, gateway subscriptions, chargeback fees, and payment-processing prices. Those commercial charges should be compared independently from PCI validation expenses.
SAQ D commonly costs more because network scanning, penetration testing, evidence collection, configuration review, and remediation consume specialist time. Prices vary widely by geography, merchant size, technology, findings, and assessor rates; neither PCI SSC nor the payment brands publish a universal SAQ filing fee for ordinary merchants. The merchant may need external support even for SAQ A if its acquirer, platform, or integration has unusual requirements. A fixed-price quote is useful only after the integration and responsibility matrix have been reviewed. One vendor’s low initial price may exclude penetration testing, travel, retesting, after-hours work, or card-brand reporting.
The timing obligations should be built into the annual cycle. The merchant should plan for four external ASV scans during the year, a new SAQ on the acquirer’s annual schedule, and any required penetration tests and supporting scans. A scan that covers only one URL is not evidence that the entire applicable attack surface has been tested. Remediation deadlines depend on severity and applicable program rules rather than one universal number. Merchants should not wait until renewal week to ask an assessor whether their architecture qualifies, because an incorrect SAQ can require a larger assessment, new evidence, and further remediation.
Why Platform and Provider Claims Can Mislead
A marketplace or platform provider can operate a compliant payment flow, but the commercial relationship may still impose operational restrictions. The provider might prohibit collecting card details through merchant support, require use of its hosted checkout, limit access to sensitive administrative functions, or insist that updates be installed automatically. Those restrictions can reduce the systems covered by the merchant’s PCI assessment, yet they do not remove all responsibility for protecting customer accounts and the merchant’s own web environment. A merchant should review the provider agreement as well as the technical statement of responsibility.
Marketing language is a poor substitute for architectural evidence. Terms such as “PCI certified,” “Level 1,” “tokenized,” and “zero card data on your server” are not interchangeable with SAQ eligibility. PCI DSS does not formally certify individual merchants as “Level 1” or “Level 2” in the way some websites imply; levels 1 through 4 principally describe how an acquirer validates a merchant, while the SAQ is the merchant’s assessment mechanism. Tokenization can remove card data from part of a flow, but tokens are still sensitive when they can be used to initiate payments. Merchants should ask what data the integration handles, not merely whether numbers appear visually in their own interface.
The most reliable provider answer names the service, describes the data flow, confirms that its current PCI DSS Attestation of Compliance covers the relevant service, and states the supported integration method. Merchants should preserve that evidence and compare it with the live implementation. Quarterly review is sensible because a provider may migrate infrastructure, change script delivery, or modify service scope. A once-only questionnaire at onboarding can become outdated even if the merchant has made no code changes.
Common Mistakes That Produce the Wrong SAQ
The most common mistake is selecting the questionnaire before understanding the payment architecture. Merchants frequently equate a polished checkout page with a hosted page, while an invisible tokenization endpoint still transmits card data through a merchant-controlled system. Another frequent error is accepting an iframe exemption without checking the current embedded-script conditions. Those conditions are technical and version-specific; older blog posts and generic processor diagrams can describe a design that no longer qualifies or lacks the necessary provider confirmation.
The second major mistake is allowing multiple channels without assigning scope. A merchant might begin with a qualifying hosted page, later add a saved card for recurring billing, and then connect an invoicing system to the same database. A third mistake is treating the payment vendor’s responsibility matrix as automatically binding on card brands and the acquirer. Although contracts allocate duties, cardholder data remains in scope wherever it is stored, processed, or transmitted. Merchants should escalate disagreements to the acquirer and, where clarification remains unclear, the payment brand rather than selecting a convenient answer.
The third mistake is failing to reconcile assessments with service changes. A merchant may complete SAQ A correctly, then install a plugin that captures payment details or move a return URL into an untrusted domain. The fourth is using old PCI DSS material. PCI DSS v4.0 and v4.0.1 introduced changes, and transition and future-dated requirements mean that assessment plans must account for the effective dates applicable to their environment. A 2022 integration guide is not adequate authority for a 26 September 2026 decision. Merchants should use the current standard, SAQ, FAQ, and acquirer instructions and save the versions they assessed.
When a Merchant Should Reassess or Seek Formal Help
A merchant should reassess immediately before launching a new checkout, changing processors, accepting card payments through a mobile application, or adding a marketplace. It should also reassess after an acquisition, a major website migration, a move to a new payment page architecture, or the addition of stored credentials, recurring payments, token storage, call-center capture, or downloadable cards. These are not only compliance events: they change exposure, and a weaker integration can add fraud, chargeback, outage, and breach risk. Security improvements and risk classification should be considered even when the acquirer requests only an annual form.
Small merchants with one qualifying hosted checkout may be able to complete the process with internal staff and their acquirer’s guidance. A qualified assessor is not automatically required to complete SAQ A, unlike the full PCI DSS assessment required in some SAQ D programs, but the merchant must follow the current questionnaire and acquirer instructions. Formal help becomes sensible when multiple processors touch the flow, cardholder data reaches servers, several legal entities share infrastructure, custom JavaScript collects sensitive data, or previous assessments disagree.
A merchant should also seek help when a vulnerability is found, a provider cannot confirm eligibility, or a breach or suspected compromise is suspected. PCI remediation deadlines alone are not a substitute for incident containment, customer notification, forensic response, and legal advice. The final decision should be signed off by the person accountable for compliance, but technical owners should verify the flow rather than relying on an account manager’s verbal assurance. Waiting until the annual deadline creates avoidable risk because the choice of SAQ affects controls, evidence, testing, cost, and potential breach exposure.
The practical conclusion is therefore straightforward but conditional: evaluate SAQ A first when a qualifying provider-hosted or embedded payment design fully isolates cardholder data, and expect SAQ D when the merchant’s web or application environment stores, processes, or transmits it. Confirm the current eligibility language and validation duties with the acquirer, then maintain the answer through quarterly reviews and whenever the payment flow changes. That process is less about finding the smallest form and more about producing an assessment that matches how payments really work.