SAQ A vs. SAQ A-EP: What’s the Difference and Which One Applies?

Outsourcing payment processing can reduce your PCI DSS scope, but it does not automatically put your ecommerce environment into SAQ A.

Two merchants can use the same third-party payment processor and still have different PCI DSS responsibilities because their checkout pages work differently. One merchant may send customers to a payment page delivered entirely by the processor. Another may build the payment form itself while sending the card data directly from the customer's browser to that processor.

That distinction matters.

SAQ A and SAQ A-EP are both Self-Assessment Questionnaires used to validate PCI DSS compliance in certain outsourced ecommerce environments. The right one depends on the actual payment architecture: where payment-page elements originate, how much influence the merchant's website has over the transaction, and whether account data ever enters merchant-controlled systems.

Understanding those mechanics is the starting point for getting PCI DSS scope right.

» Find out how to accurately complete a PCI DSS SAQ for compliance success

What is the difference between SAQ A and SAQ A-EP?

For SAQ A, the payment-page elements delivered to the customer's browser must originate only from, and be delivered directly by, PCI DSS-compliant third-party service providers.

SAQ A-EP addresses e-commerce environments where the merchant's website does not itself receive account data but can affect the security of the payment transaction or the integrity of the page that accepts that data. You must meet all eligibility criteria for the relevant SAQ; satisfying one architectural condition is not enough on its own.

A useful high-level comparison looks like this:

The last row is especially important. SAQ A versus SAQ A-EP is not always a binary choice. If your systems electronically receive, process, transmit, or store account data, you may need a different SAQ or validation approach.

Payment-page origin

One of the clearest technical distinctions is who creates the payment page that the customer interacts with.

PCI SSC states that, for SAQ A eligibility, all payment-page elements delivered to the customer's browser must originate only and directly from PCI DSS-compliant service providers. No payment-page element can originate from the merchant website. For SAQ A-EP, individual payment-page elements can originate from either the merchant or a compliant service provider.

That makes payment-page origin more useful than asking whether you "use a third-party processor."

A checkout page can look like part of your website, while the processor supplies the payment form inside an iframe. Conversely, the card data can be sent directly to the processor while the merchant still creates the fields into which the customer types the card number.

Those two configurations do not create the same security exposure.

Scope and security responsibilities

SAQ A-EP carries a broader set of PCI DSS responsibilities because merchant-controlled ecommerce systems play a larger role in payment security.

The questionnaire covers applicable controls across areas such as secure configuration, malware protection, secure software development, access management, authentication, logging and monitoring, vulnerability management, security testing, and information-security processes. The precise requirements depend on the current questionnaire and the merchant's environment.

That is why choosing between SAQ A and SAQ A-EP shouldn't start with, "Which questionnaire has fewer requirements?"

The better question is, "Which questionnaire accurately represents how our payment flow works?"

Current SAQ A responsibilities should not be described as "nothing"

SAQ A is narrower, but that doesn't mean the merchant website can be ignored.

Under the current PCI DSS v4.0.1 SAQ A, e-commerce merchants using an embedded third-party payment page or form, such as an iframe, must meet an eligibility criterion confirming that the merchant site is not susceptible to script attacks that could affect the e-commerce system. PCI SSC explains that this particular criterion applies to embedded payment pages/forms, not ordinary redirects or situations where payment functions are completely outsourced.

Current SAQ A also includes external vulnerability scanning requirements for merchant e-commerce webpages that redirect transactions to a third-party provider or contain the provider's embedded iframe. PCI SSC clarified in June 2026 that the applicable scans must be conducted through a PCI SSC Approved Scanning Vendor (ASV).

So "SAQ A" should not be interpreted as "our website has no PCI DSS security responsibilities."

Struggling to determine your SAQ type?

Let our QSA experts scope your environment and guide your PCI DSS assessment from start to finish

Talk to Us

Why does PCI DSS separate SAQ A from SAQ A-EP?

PCI DSS separates the two because payment data can be compromised before it ever reaches the payment processor.

An e-commerce website does not need to store a card number in its database to create payment risk. If an attacker compromises merchant-controlled code that influences the checkout page, that code may be able to change where information is sent, modify the page presented to the customer, or capture cardholder data as the customer enters it.

That is the security issue behind the SAQ A-EP model.

How a site can compromise payment data without receiving it

Consider a merchant whose payment form sends card data directly from the customer's browser to a payment processor.

From a backend perspective, the merchant's server may never receive the card number. That makes it seem like the merchant is outside the flow.

But if the merchant controls the HTML or JavaScript that builds the payment form, a compromised merchant website could potentially inject malicious code into that page. The malicious script could copy the card data and send it somewhere else while the legitimate transaction continues normally.

PCI SSC specifically identifies this type of malicious JavaScript attack as a risk associated with merchant-created payment pages.

The useful distinction, then, is not only: Does our server receive card data?

It is also: Can our systems affect the page where the customer enters that data?

That second question is what catches many ecommerce businesses out.

Why Direct Post and merchant-created payment forms receive greater scrutiny

Direct Post is a good illustration.

In a Direct Post implementation, the merchant website produces some or all of the page used to accept payment information, while the customer's browser sends that information directly to the third-party payment processor. The merchant may never electronically receive the account data, but its website still controls part of the mechanism used to collect it.

With a qualifying redirect or iframe implementation, by contrast, the payment processor produces the page or form that accepts the payment data.

PCI SSC identifies this difference as the reason Direct Post aligns with SAQ A-EP, while qualifying iframe or redirect implementations can align with SAQ A.

That is why "the cards never touch our servers" is useful information, but not enough information to determine your SAQ.

» New to PCI DSS? Learn how to determine the right SAQ and take the first steps toward compliance.

SAQ A vs. SAQ A-EP: How payment architectures change the answer

The easiest way to understand SAQ A vs. SAQ A-EP is to look at common checkout architectures.

Names like "hosted payment," "embedded checkout," or "API payment" can be misleading because vendors don't always use them consistently. PCI DSS scope depends on what the integration actually does.

Provider-hosted redirect

In a redirect model, a customer begins on the merchant website and is sent to a payment page supplied by the payment provider to enter card details.

This is a typical SAQ A architecture when all applicable eligibility criteria are met because the provider, rather than the merchant, produces the payment page that accepts the account data. PCI SSC explicitly identifies URL redirects as one of the payment approaches associated with SAQ A.

The merchant still has responsibilities. Among other applicable requirements, current PCI SSC guidance confirms that SAQ A e-commerce webpages performing these redirects are subject to the relevant ASV scanning requirements.

Embedded provider-hosted iframe

An iframe does not automatically mean SAQ A-EP.

If the payment page or form embedded inside the merchant webpage originates from the PCI DSS-compliant payment provider and the merchant meets the other SAQ A eligibility criteria, an iframe implementation can qualify for SAQ A.

However, there is an important current qualification.

For ecommerce merchants using an embedded third-party payment page or form, SAQ A r1 includes an eligibility criterion related to susceptibility to script attacks. PCI SSC says merchants can address that criterion through suitable protections or by obtaining confirmation from the compliant payment provider that its solution, when implemented according to its instructions, includes techniques protecting the merchant payment page from script attacks.

This is exactly why old shortcuts such as "iframe equals minimal PCI responsibility" are no longer sufficient.

Direct Post or merchant-generated payment form

Suppose the merchant's own website renders fields for card number, expiration date, and other payment information. When the customer submits the form, the browser sends the card data directly to the processor.

The merchant's backend may never receive the card data.

But because the merchant created the payment page, the merchant environment can affect how payment data is captured and transmitted. That is the type of environment SAQ A-EP is designed to address.

This typically means a much broader portion of the merchant's ecommerce security controls needs to be assessed.

Server-side/API handling of payment data

"API integration" by itself tells you very little about PCI DSS scope.

One API-based implementation might tokenize payment information in the customer's browser so the merchant receives only a token. Another might post raw card data to the merchant's application server, which then sends it to the payment processor.

Those are very different architectures.

If account data enters merchant-controlled systems, the eligibility conditions for SAQ A and SAQ A-EP may no longer be met. SAQ A-EP is intended for merchant websites that can affect the transaction but do not receive account data and do not electronically store, process, or transmit it.

Do not classify an integration by the word "API." Trace the data.

How can businesses determine whether they qualify for SAQ A or SAQ A-EP?

Start by mapping the real checkout flow as it operates today.

Do not base your decision solely on what your payment provider calls its product, what last year's SAQ said, or the assumption that outsourcing equals SAQ A.

Questions to ask your engineering and payment teams

Work through the payment flow from the customer's browser to the processor:

1. Who creates the payment form?
   • Is the HTML/form supplied entirely by the payment provider, or does your application generate any payment-page elements?
2. Where do the checkout scripts originate?
   • Understand both payment-provider code and merchant-controlled code running around the checkout.
3. Where does the customer enter account data?
   • Is it entered on a separate provider-hosted page, inside a provider-hosted iframe, or into elements created by your website?
4. Where does that data go next?
   • Trace it from the browser. Does it travel directly to the payment processor, or does any merchant-controlled server receive it first?
5. Can your code change or influence the payment experience?
   • Consider templates, JavaScript, tag managers, ecommerce plugins, frontend frameworks, and other components that can affect checkout.
6. Do you electronically store account data anywhere?
   • Check application databases, logs, message queues, troubleshooting tools, analytics, support systems, backups, and integrations rather than assuming the answer is no.
7. Which third parties are involved, and are they PCI DSS compliant for the services you use?
8. Has anything changed since your previous assessment?
   • A new payment provider, checkout redesign, script, plugin, integration, or frontend architecture can change the answer.

Once you understand those facts, compare the environment with the complete current eligibility criteria, not a simplified internet decision tree.

PCI SSC also advises merchants to consult the entity to which their validation is submitted, typically their acquirer or applicable payment brand, to confirm whether an SAQ is required and which one is appropriate.

Architecture indicators that point toward SAQ A

For an ecommerce merchant, characteristics associated with SAQ A include:

• Applicable account-data functions are outsourced to compliant third parties.
• Merchant systems do not electronically store, process, or transmit account data.
• Payment-page elements delivered to the customer's browser originate only from, and are delivered directly by, compliant third-party providers.
• The payment flow uses a structure such as a qualifying provider-hosted redirect or iframe.
• The merchant meets all other current SAQ A eligibility criteria, including the applicable ecommerce script-security criterion where relevant.

No single item guarantees SAQ A eligibility. The criteria work together.

Architecture indicators that point toward SAQ A-EP

SAQ A-EP applies when the merchant does not electronically handle account data, but its ecommerce website has greater influence over payment security. Indicators can include:

• The merchant generates some or all payment-page elements.
• Merchant-controlled code influences how account data is collected or redirected.
• The implementation uses a Direct Post-style flow.
• The merchant website can affect the integrity of the page accepting payment data.
• Account-data processing beyond the payment page remains outsourced to compliant third parties.

SAQ A-EP applies only to ecommerce channels and requires the merchant to satisfy its full eligibility criteria.

Signs that neither SAQ may fit

Don't force the environment into A or A-EP just because those are the two ecommerce questionnaires you are comparing.

Take a closer look if:

• Raw account data reaches your application server.
• A server-side service sends cardholder data to the processor.
• Merchant systems electronically store account data.
• Logs, integrations, or support tools capture account data.
• Your architecture does not satisfy all eligibility conditions for either questionnaire.

In these cases, the right next step is to determine the actual PCI DSS scope and appropriate validation method rather than trying to make the implementation fit a preferred SAQ.

Why accurate SAQ scoping matters beyond the questionnaire

The goal of scoping is not to get the shortest possible questionnaire. It is to ensure the assessment reflects the environment that affects payment security.

If you under-scope the environment and applicable controls, systems, evidence, or testing may be omitted. If that error is identified later, the organization may have to revisit architecture, collect additional evidence, remediate controls, or change its assessment approach when deadlines are already tight.

Over-scoping creates a different problem: teams may spend engineering and compliance time applying controls to systems that did not need to be included.

Getting the payment flow clear early avoids both problems.

Revisit scope rather than treat it as permanent. Review the classification when you:

• Change payment processors;
• Switch between redirect, iframe, Direct Post, or server-side payment methods;
• Redesign checkout;
• Add scripts, tags, plugins, or third-party integrations;
• Change how payment tokens or account data move through the application;
• Introduce new systems that log or otherwise handle payment information.

A small checkout change can alter the technical facts behind the previous SAQ determination.

» Struggling with difficult PCI DSS SAQ questions? Get expert guidance to interpret requirements, validate your answers, identify gaps, and prepare the right evidence.

Confirm your PCI DSS SAQ scope with GRSee

Understanding the difference between SAQ A and SAQ A-EP is relatively straightforward on paper. Mapping a real ecommerce stack to those criteria can be harder, especially when checkout combines payment-provider components, merchant JavaScript, APIs, third-party tags, and cloud services.

GRSee's PCI DSS SAQ services start with the payment flow. We review how your organization handles account data, determine the applicable SAQ, and identify legitimate opportunities to reduce unnecessary PCI DSS scope without overlooking systems that can affect payment security. Our current PCI DSS SAQ offering also includes gap assessment, remediation planning, implementation support, SAQ completion, and QSA involvement where appropriate.

The objective is not to push the environment toward SAQ A. It is to establish the correct scope early, understand what your team is actually responsible for, and give you a practical path through the assessment.

If you are unsure whether your redirect, iframe, Direct Post, or custom payment integration belongs in SAQ A or SAQ A-EP, the useful next step is to review the architecture before completing the questionnaire.