SAQ A vs SAQ A-EP vs SAQ D: Which PCI Self-Assessment Questionnaire Applies to Your Checkout?

Overview

Here is the short version: the PCI self assessment questionnaire you need depends less on what your business sells and more on how cardholder data flows through your checkout.

For most digital merchants deciding between SAQ A vs SAQ A-EP vs SAQ D, the central question is whether your systems are truly removed from the collection, processing, or transmission of cardholder data, or whether your website still plays an active role in the payment page experience.

At a high level:

• SAQ A is generally associated with fully outsourced payment collection where the merchant has a tightly limited PCI scope.
• SAQ A-EP is commonly relevant when the merchant’s website can affect the security of the payment page, even if card data is ultimately posted to a third-party processor.
• SAQ D is the broad, catch-all questionnaire for merchants whose environments handle payment data directly or do not clearly fit a narrower SAQ category.

That sounds simple, but checkout design often blurs the lines. A redirect to a hosted payment page usually points toward a smaller scope than a custom payment form. An embedded iframe can reduce exposure, but it does not automatically make every implementation eligible for SAQ A. JavaScript loaded from your site, checkout page control, postMessage logic, DOM manipulation, and surrounding page security all matter.

This is why which PCI SAQ do I need is really an architecture question. Your payment gateway choice matters, but your integration pattern matters more. A merchant using a modern payment API can end up in very different PCI positions depending on whether checkout is hosted, embedded, tokenized in-browser, or fully server-controlled.

If you need background on the broader payments stack, see Payment Gateway vs Payment Processor vs Merchant Account: Differences, Costs, and When You Need Each. If you want a wider merchant checklist beyond SAQ classification, see PCI DSS Compliance Checklist for Online Payments: What Merchants Need to Do.

How to compare options

The fastest way to compare SAQ A, SAQ A-EP, and SAQ D is to stop thinking in labels and start thinking in payment data flow, page control, and system influence. The following framework helps.

1. Map exactly where card data is entered

Start with the literal customer journey:

1. Where does the card number appear on screen?
2. What domain hosts that page or input field?
3. What JavaScript runs on that page?
4. Where is the form submitted?
5. Can your application, plugins, tags, or scripts alter what the customer sees before submission?

If customers are redirected away from your site to a provider-hosted payment page and card data is entered there, your environment may be more limited in scope. If the payment form lives on your site, even if the processor receives the data, scope usually expands.

2. Separate “touching data” from “influencing the payment page”

Many teams understand direct handling of card data, but underestimate indirect influence. That is often where PCI scope checkout decisions become difficult.

A merchant website may never store card numbers and still affect the integrity of the payment experience. If your server delivers the checkout page, controls scripts, manages template rendering, or can modify the payment form environment, that tends to move you away from the simplest SAQ assumptions.

3. Review your integration model, not just your vendor

Two businesses can use the same payment gateway and end up in different SAQ categories. What matters is implementation:

• Hosted payment page redirect: often lower scope.
• Embedded provider checkout or iframe: scope depends on how much your page controls or surrounds the payment experience.
• Client-side tokenization: reduces exposure, but does not automatically eliminate SAQ A-EP or SAQ D considerations.
• Direct post or server-side API collection: usually broader scope, often leading toward SAQ D.

For a deeper look at integration trade-offs, see Hosted Payment Pages vs Direct API Integrations: Security, UX, and Compliance Trade-offs and Best Payment Gateway APIs for Developers: Comparison by Features, Docs, Webhooks, and SDKs.

4. Inventory what your website can change

This is one of the most useful tests. Ask:

• Can marketing tags, tag managers, A/B testing tools, or third-party widgets run on checkout?
• Can CMS plugins or theme code alter the checkout DOM?
• Can your application inject scripts near the payment component?
• Do admins or developers have change access without formal review?
• Are there custom checkout enhancements that interact with payment elements?

The more your environment can alter the page that presents payment collection, the less likely it is that you are in the narrowest scope.

5. Document assumptions before selecting an SAQ

Teams often jump straight to the questionnaire name. A better approach is to write a one-page scope memo that states:

• how the checkout works,
• which systems host or render the payment experience,
• whether card data traverses merchant servers,
• whether the merchant website can affect the payment page, and
• which SAQ seems to align with that design.

This creates a cleaner internal record and makes later reassessment easier when architecture changes.

Feature-by-feature breakdown

This section compares the three questionnaires in practical terms rather than legalistic shorthand. It is a guide to reasoning, not a substitute for reviewing official PCI documentation and your provider’s implementation details.

SAQ A: best aligned with fully outsourced payment collection

Typical fit: A merchant outsources the payment function so that cardholder data entry happens on infrastructure controlled by a PCI-compliant service provider, with very limited merchant involvement in the payment page itself.

Common pattern: The customer clicks checkout on the merchant site and is redirected to a hosted page, or another similarly outsourced experience where the merchant environment does not receive or materially control card entry.

Why businesses aim for it:

• Smaller compliance scope
• Less direct responsibility for card data environments
• Simpler operational model for many small and mid-sized merchants

Where teams make mistakes:

• Assuming any outsourced processor means SAQ A
• Ignoring website security because “we never store cards”
• Treating embedded checkout as equivalent to full redirect without checking scope implications

Practical caution: If your site still hosts the page that presents the payment experience, or if your scripts can influence the payment component, you may need to look more closely at SAQ A-EP instead.

SAQ A-EP: for ecommerce sites that affect the payment page

Typical fit: An ecommerce merchant outsources payment processing but maintains a website that can impact the security of the payment transaction page.

Common pattern: The merchant serves the checkout page and integrates payment elements, scripts, redirects, or form logic in a way that means the site remains relevant to payment page security.

Why it exists: Because website compromise can still expose customers even when card data is sent to a third party. If an attacker can alter your checkout page, inject malicious JavaScript, or manipulate payment fields, outsourcing the endpoint alone does not remove the security risk.

Operational reality: SAQ A-EP often catches merchants who believed tokenization or a gateway-hosted field made them “out of scope.” In practice, the merchant site may still need stronger controls around application security, change management, patching, vulnerability handling, and web checkout hardening.

Common indicators that point toward SAQ A-EP:

• Your domain serves the checkout page.
• Your application loads scripts on the payment page.
• Your team controls the surrounding HTML, CSS, or JavaScript.
• Your environment could be compromised in a way that changes what the customer sees before submitting payment details.

Practical caution: A-EP is often the “look again” category for modern ecommerce. It is especially important for custom storefronts, headless commerce, CMS-driven checkout pages, and heavily scripted frontend experiences.

SAQ D: the broadest merchant questionnaire

Typical fit: Merchants that store, process, or transmit cardholder data in their own environment, or whose implementations do not fit the narrower SAQ categories.

Common pattern: Direct API collection, server-side handling of payment data, custom-built payment pages with merchant-controlled submission flows, or mixed architectures with unclear boundaries.

Why it matters: SAQ D is usually the most comprehensive route. It reflects the reality that your systems are materially part of the cardholder data environment or connected security environment.

What often pushes teams into SAQ D:

• Card data passes through merchant servers.
• Applications store sensitive payment-related data improperly or historically.
• Legacy systems were never redesigned for scope reduction.
• Custom middleware, proxies, logging, debugging, or observability layers expose payment flows.
• The architecture is too complex or hybrid to fit a simpler SAQ with confidence.

Practical caution: Some teams try to design around SAQ D without fully redesigning the flow. Partial tokenization, selective field isolation, or provider-side vaulting may reduce risk, but if your environment still handles payment data directly, the broader questionnaire may still apply.

A quick comparison table in plain English

• SAQ A: best when payment collection is truly outsourced and the merchant site has minimal payment-page involvement.
• SAQ A-EP: best when payment is outsourced but the merchant website still affects the security of checkout.
• SAQ D: best when the merchant environment handles payment data directly or falls outside narrower categories.

How security tooling changes the picture

Security controls such as tokenization for card payments, content security controls, file integrity monitoring, vulnerability management, and hardened deployment practices are valuable in every model. But they do not change SAQ category by themselves. They help you secure your environment; they do not automatically shrink your scope.

This matters for teams building PCI compliant payment processing workflows. A secure architecture starts with reducing exposure where possible, then matching controls to remaining scope. If you want to operationalize that work, Automating PCI Compliance Workflows for DevOps Teams in Payment Systems is a useful next read.

Best fit by scenario

The most useful way to answer which PCI SAQ do I need is to map common checkout scenarios to likely outcomes. The examples below are directional, not definitive.

Scenario 1: Redirect to a provider-hosted checkout page

Likely direction: SAQ A may be the best fit if the card entry page is fully hosted by the payment provider and your site is not controlling that payment page in a material way.

Why: This model usually creates the cleanest separation between merchant infrastructure and card data collection.

Watch for: custom scripts, pre-checkout data collection, misleading assumptions about connected systems, and whether your implementation still embeds or alters the payment experience.

Scenario 2: Merchant-hosted checkout page with embedded payment fields or iframe components

Likely direction: Often SAQ A-EP territory, especially if your site serves the page and can influence the security of the customer payment experience.

Why: Even if the processor-hosted component receives the card details, your checkout page can still be a point of compromise.

Watch for: tag managers, third-party JavaScript, CMS plugins, frontend release practices, and script integrity.

Scenario 3: JavaScript tokenization on your checkout page

Likely direction: Frequently A-EP, and in some implementations possibly broader, depending on how the flow works.

Why: Tokenization reduces direct exposure, but the merchant-hosted page often still matters to payment security.

Watch for: whether any raw cardholder data touches your app, browser logs, monitoring tools, or backend systems.

Scenario 4: Direct API card capture through your servers

Likely direction: SAQ D.

Why: Merchant systems are directly involved in processing or transmitting payment data.

Watch for: debugging, logging, retries, temporary storage, support tooling, and network segmentation assumptions.

Scenario 5: Legacy ecommerce stack with unclear plugins and inherited checkout code

Likely direction: Do not assume a narrow SAQ. Many of these cases require a careful reassessment and may land in A-EP or D depending on actual data flow and page control.

Why: Legacy codebases often contain undocumented scripts, extensions, and integrations that affect checkout security.

Watch for: abandoned modules, stale dependencies, admin access sprawl, and server-side customizations.

Scenario 6: SaaS billing with provider-hosted customer portal

Likely direction: Often closer to SAQ A if the billing portal and card update flows are fully hosted by the payment provider.

Why: Recurring billing and subscription management can sometimes be designed to keep card collection outside the merchant environment.

Watch for: custom invoice payment pages, branded embedded forms, and any place where the main application regains control over card entry.

For adjacent topics that affect payment operations, see Securing Webhooks and Callbacks in Payment Integrations: Patterns for Reliability and Designing Real-Time Payment Analytics for Fraud Detection and Ops Monitoring.

When to revisit

Your SAQ classification should be revisited any time your checkout architecture, payment gateway integration, or website control model changes. This is the practical discipline that keeps a past compliance decision from becoming an inaccurate habit.

Reassess your payment environment when any of the following happens:

• You switch integration models. Moving from hosted pages to embedded fields, or from embedded fields to direct API collection, can change PCI scope significantly.
• You redesign checkout. A new frontend framework, headless storefront, or custom billing flow may give your site more influence over the payment page.
• You add third-party scripts. Analytics, personalization, testing, fraud tools, chat widgets, and tag managers can all affect the security profile of checkout.
• You change platforms. Replatforming ecommerce, migrating CMS, or adopting a new subscription billing system can alter who hosts what.
• You expand globally. New payment methods, multi-currency flows, and local payment pages can introduce architectural variation. See Multi-Currency Payment Handling: Best Practices for Conversion, Reconciliation, and UX.
• You introduce custom fraud or analytics logic. Helpful controls can also create new data paths if implemented carelessly.
• Your provider updates products or documentation. A new checkout component, hosted wallet flow, or tokenization approach may reduce or expand scope depending on use.
• You discover legacy systems in the flow. Logging layers, reverse proxies, support tools, or old admin consoles often matter more than expected.

A practical next step is to create an internal SAQ review checklist:

1. Draw the current payment data flow.
2. List every domain, app, script source, and service involved in checkout.
3. Mark where card data is entered and where it could be intercepted or altered.
4. Identify whether your environment hosts, renders, or can modify the payment page.
5. Document the likely SAQ classification and the assumptions behind it.
6. Review that document after every meaningful checkout change.

This approach keeps your PCI DSS compliance for payments grounded in actual system design rather than old vendor sales language or one-time implementation notes.

The most important takeaway is simple: do not choose SAQ A because it sounds easier, and do not assume SAQ D just because your stack is technical. Start with architecture, validate scope honestly, and make checkout design decisions that reduce exposure where they truly can. That is the most reliable path to secure online payments, cleaner compliance reviews, and fewer surprises as your payment processor, gateway, or business payment solutions evolve.

If your team is evaluating future-state architecture, it may also help to compare compliance implications alongside cost and product flexibility. These related guides can help: Payment Processing Fees Explained: Interchange, Assessment, Markup, and Hidden Costs and Technical Tactics to Reduce Card Processing Fees for Payment Platforms.