SAQ A or SAQ A-EP? Integration by integration (PCI DSS v4.0.1, 2025 update)

Your bank or processor wants your PCI self-assessment, and you sell online. The choice is usually SAQ A or SAQ A-EP, and it turns on one question: who supplies the boxes your customer types their card number into? The January 2025 revision of SAQ A changed what a checkout with embedded payment fields must do to qualify. Here is the rule, what changed, and how the common payment integrations come out, each linked to the provider's own documentation so you can check.

The rule

Under PCI DSS v4.0.1, with SAQ A as revised in January 2025 (in effect from 31 March 2025) and PCI SSC FAQ #1588 (February 2025):

• SAQ A: every element of the payment page or form delivered to the customer's browser comes only and directly from a PCI DSS compliant payment provider. There are two ways to get there, and both count:
  1. Redirect. The customer is sent to the provider's own payment page.
  2. Embedded. The provider's payment form, or its individual card fields, sit in your page as iframes served by the provider (often called hosted fields, a hosted payment form, a lightbox or drop-in). Your page surrounds them; it never creates, reads or submits the card fields. For this route only, you must also confirm that "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)". That is the script criterion.
• SAQ A-EP: your website does not receive card data, but your own page builds or submits the card form: a direct-post form, or a script that reads card boxes on your page and sends them to the provider. Also SAQ A-EP: provider fields embedded in your page when you cannot meet the script criterion.
• SAQ D: card numbers reach your server, even for a moment (your form posts to your back end, which calls the provider's API).

Which domain is in the address bar does not decide it. Neither does your provider being "PCI compliant": almost every provider offers both a SAQ A integration and others that are not.

How to tell which one you have

1. When customers type their card number, whose boxes are they typing into? Your payment provider's (its own page, or its secure fields shown inside your checkout) points to SAQ A. Boxes your website built, even if the details go straight to the provider, mean SAQ A-EP. If you are not sure, ask your developer or look at the integration's name in your provider's dashboard and find it in the table below.
2. Does the card number ever reach your server? If your own back end receives it, even just to pass it on, it is SAQ D, not A or A-EP.
3. If the provider's fields are embedded in your page: can you confirm your checkout is protected against malicious scripts? Yes, with your provider's written confirmation or your own payment-page script controls: SAQ A. No: SAQ A-EP. If customers are redirected to the provider's page, this question doesn't apply.

Integration by integration

How to read it. Stated by… means the provider's own documentation names the SAQ. Not stated by…, follows the rule means we could not find an SAQ statement in the provider's own documentation, so the row applies the rule above; confirm it with your provider. + script criterion means the provider's fields sit inside your page, so SAQ A also needs the script confirmation. Sources were checked on 18 October 2026.

A few provider details that don't fit a row. Adyen says it does not require PCI DSS documentation for its Pay by Link product, and that it requires only SAQ A for its older client-side encryption integrations (closed to new integrations) because you cannot decrypt the card data: a case where the acquirer's own requirement decides. Clover says its API-only integration "requires higher PCI compliance and PCI DSS certification". Products and documentation change; the provider's current documentation and your acquirer have the final word.

What changed in 2025

• 2022, PCI DSS v4.0. Two new requirements for e-commerce payment pages: 6.4.3 (manage the scripts on the payment page) and 11.6.1 (detect tampering with the payment page). SAQ A included them, as future-dated requirements that became mandatory on 31 March 2025.
• October 2024, SAQ A for v4.0.1. A new SAQ A for the limited v4.0.1 revision of the standard, still including 6.4.3 and 11.6.1, and Requirement 12.3.1 (the targeted risk analysis that supports 11.6.1).
• January 2025, SAQ A revised. In response to stakeholder feedback, PCI SSC removed 6.4.3, 11.6.1 and 12.3.1 from SAQ A and added the eligibility criterion that the merchant "has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)". The revision took effect on 31 March 2025, when the October 2024 version was retired. The requirements stay in PCI DSS itself. PCI SSC announcement, 30 January 2025
• February 2025, FAQ #1588. PCI SSC explained how to meet the new criterion: it applies only to pages with a provider's embedded payment page or form, not to redirects, and it is met either with techniques such as those in 6.4.3 and 11.6.1 or with the provider's confirmation. PCI SSC FAQ #1588
• March 2025. PCI SSC published an information supplement, Payment Page Security and Preventing E-Skimming: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1, for merchants who apply those controls. PCI SSC, 26 March 2025
• June 2026, FAQ #1604. PCI SSC confirmed that SAQ A's external vulnerability scans by an Approved Scanning Vendor (Requirement 11.3.2) apply to merchant webpages that redirect to a provider and to webpages with a provider's embedded iframe. PCI SSC FAQ #1604

The practical effect: payment pages loaded in a provider's iframe have counted toward SAQ A since PCI SSC's 2015 guidance on direct post versus iframes and redirects (FAQ #1292). What changed in 2025 is what an embedded merchant has to do to stay there: instead of meeting 6.4.3 and 11.6.1 inside SAQ A, it confirms the script criterion, usually with its provider's confirmation. The "which domain is the customer on" shortcut that still circulates was never the test.

How to satisfy the script criterion

It applies only when your provider's fields or form are embedded in your page. FAQ #1588 gives two ways to meet it:

1. Get your provider's written confirmation, and keep it on file. Ask your PCI DSS compliant provider to confirm that its embedded solution, implemented according to its instructions, includes techniques that protect your payment page from script attacks. Implement it exactly as instructed, and keep the confirmation with your SAQ and your provider's Attestation of Compliance. Providers' instructions increasingly include a Content Security Policy: Square requires one for its Web Payments SDK from 1 October 2025, Stripe publishes the policy directives for its products, and Adyen recommends a Content Security Policy and Subresource Integrity. (Square, Stripe, Adyen)
2. Or protect the page yourself, or through a third-party service, with techniques such as those in the two requirements SAQ A no longer lists:
   • 6.4.3: every script that runs on the payment page is authorized, its integrity is checked, and it is on an inventory with a written reason it is needed.
   • 11.6.1: a change- and tamper-detection mechanism alerts you to unauthorized changes to the payment page's security-relevant headers and content as the customer's browser receives it, at least weekly.

If you can do neither, the embedded setup is SAQ A-EP. Switching to your provider's redirect (its own hosted payment page) is the other way back to SAQ A without the script criterion.

Common mistakes

• "The customer never leaves our domain, so it's A-EP." The old shortcut. A provider's embedded fields always sit on your domain, and some provider-built checkouts (Square Online, for one) run on your own domain too. What matters is whether the card form itself is the provider's.
• "Our provider is PCI compliant, so we're SAQ A." The provider's compliance is necessary, not enough. Authorize.Net, Stripe and Adyen each document integrations at more than one SAQ level, from SAQ A to A-EP or D. Your integration decides.
• Loading analytics, tag-manager, chat or A/B-testing scripts on the payment page. Every script on the page that hosts the provider's fields is code that could be swapped for a card skimmer, and it is exactly what the script criterion is about. Keep the checkout page lean, and make sure whatever confirmation or controls you rely on covers what is actually loaded there.
• "An iframe is always SAQ A." Only if the iframe and everything in the card form come directly from your PCI DSS compliant provider, and you meet the script criterion. Card boxes your site draws inside its own frame are still your form.
• Forgetting the scans. SAQ A still includes quarterly external vulnerability scans of your e-commerce pages by an Approved Scanning Vendor.

For ISOs, acquirers and PayFacs

Across a portfolio, the "which domain" shortcut quietly hands every merchant on Stripe Elements, Braintree Hosted Fields or an Authorize.Net lightbox the considerably longer SAQ A-EP, when the providers' own documentation says SAQ A. Merchants answer more questions than they need to, and more of them stall before finishing.

Compliance Assessment Tool decides per payment method, using the rule on this page. When a merchant's description only names a gateway ("we take cards on our website through Authorize.Net"), it does not guess. It asks one plain-English question:

The answer settles SAQ A, A-EP or D. For embedded fields, CAT chooses SAQ A and tells the merchant they will need to confirm the script criterion, usually by keeping their provider's written confirmation on file. See the PCI compliance API for ISOs, acquirers and PayFacs.

Common questions

Is Stripe Elements SAQ A or SAQ A-EP?

SAQ A. Stripe's PCI guide lists Checkout and Elements as SAQ A because the card inputs sit in an iframe served from Stripe's domain, and Stripe's documentation calls the Payment Element SAQ-A eligible. Because the fields are embedded in your page, you also confirm the SAQ A script criterion. The exception is the legacy Stripe.js v2 used with card boxes on your own form, which Stripe says requires SAQ A-EP.

Is an embedded payment iframe SAQ A or SAQ A-EP?

Under the January 2025 revision of SAQ A, an iframe or set of secure card fields served entirely by your PCI DSS compliant payment provider is SAQ A, as long as you can also confirm your site is not susceptible to attacks from scripts that could affect your e-commerce system. If you cannot confirm that, either through your provider's written confirmation or your own payment-page script controls, the embedded setup is SAQ A-EP.

My checkout stays on my own domain. Doesn't that make it SAQ A-EP?

No. The test is who supplies the card form, not which domain is in the address bar. A provider-built checkout can run on your own web address (Square says Square Online customers check out directly on your domain), and a provider's embedded fields always sit inside your page, yet in both cases the card form itself comes entirely from the provider. It is SAQ A-EP only when your own website builds or submits the card form.

How do I meet the "not susceptible to attacks from scripts" criterion?

PCI SSC FAQ #1588 (February 2025) gives two ways. Either protect your payment page with techniques such as those in PCI DSS Requirements 6.4.3 and 11.6.1, yourself or through a third party, or get confirmation from your PCI DSS compliant payment provider that its embedded solution, implemented according to its instructions, includes techniques that protect your payment page from script attacks. Keep whichever you rely on with your SAQ records.

Does the script criterion apply if I redirect to my provider's payment page?

No. FAQ #1588 says the criterion applies only to webpages that include a provider's embedded payment page or form, such as an iframe. It does not apply to merchants whose webpage redirects customers to the provider, or who fully outsource payment, for example by emailing customers a payment link.

Were Requirements 6.4.3 and 11.6.1 removed from PCI DSS?

No. The January 2025 revision removed them only from SAQ A, along with Requirement 12.3.1, the targeted risk analysis that supported 11.6.1. They remain in PCI DSS v4.0.1 and still apply to merchants that validate with SAQ A-EP or SAQ D.

Do SAQ A merchants still need quarterly ASV scans?

Yes, for their e-commerce webpages. PCI SSC FAQ #1604 (June 2026) says the external vulnerability scans by an Approved Scanning Vendor in SAQ A (Requirement 11.3.2) apply to merchant webpages that redirect to a payment provider and to webpages that include a provider's embedded iframe.

Who decides which SAQ I file?

Your acquiring bank or payment processor. PCI SSC tells merchants to confirm with the entity that accepts their compliance validation, and some providers set their own requirements as acquirer, for example by asking larger merchants for a different SAQ or a QSA signature. Use the rule on this page to know what to ask for, and confirm with them.

Related guides

SAQ A: who needs it · SAQ A-EP: who needs it · SAQ D · Which PCI SAQ do I need?

This guide helps you identify the right self-assessment questionnaire. Your acquiring bank or payment processor decides which SAQ you must submit — confirm with them if you are unsure. Compliance Assessment Tool helps you complete a PCI DSS self-assessment; we are not a Qualified Security Assessor (QSA) and do not certify compliance. PCI DSS rules are from PCI Security Standards Council publications linked above. Provider statements are from each provider's own documentation as checked on 18 October 2026; providers change their products and documentation, so confirm with your provider and your acquirer. Third-party names are trademarks of their owners; no provider has reviewed or endorsed this page.