← All articles · April 25, 2026 · CheckoutProof

What Is SAQ A-EP and Why Does It Apply to Your Shopify Custom Checkout?

If your acquirer asked you to fill out an SAQ A-EP instead of an SAQ A, this article explains what changed, why it applies to you specifically, and what’s actually different about the two questionnaires.

If the words “SAQ A” and “SAQ A-EP” both look like the same string of letters: stay with me. By the end of this you’ll know which one you fall under and why your situation might have shifted in 2025 even though nothing in your store changed.

The short version

• SAQ A is the short PCI questionnaire for merchants who fully outsource card handling. About 12 questions.
• SAQ A-EP is the longer questionnaire for merchants whose website controls the page that loads the payment form, even if your site never sees the card number directly. About 150 questions.
• The January 2025 amendment changed the eligibility rules for SAQ A. A lot of merchants who used to qualify for SAQ A now qualify for SAQ A-EP.
• A custom Shopify checkout (any checkout that isn’t Shopify’s default Shopify-Payments managed checkout) typically lands you in SAQ A-EP.
• A merchant using Stripe Elements on their own domain typically lands in SAQ A-EP.

If any of those last two describe you, the rest of this article is for you.

Why there are two questionnaires

PCI DSS applies to every merchant who accepts a credit card. But the actual security controls a merchant needs depend on how much exposure to card data they have.

Three rough buckets:

• Bucket 1 — The merchant never touches card data at all. The customer is redirected to a page hosted entirely by the payment processor (PayPal Standard’s old hosted checkout, for example). The merchant’s site never sees a card number, never controls the page where the card is entered, and isn’t even technically in the customer’s browser when the card is entered.
• Bucket 2 — The merchant’s site loads a page where the card is entered, but the payment form itself is an iframe served by the processor. The merchant doesn’t see the card number, but the merchant’s own HTML, JavaScript, and infrastructure are present on the page surrounding the iframe.
• Bucket 3 — The merchant’s site directly receives the card number. (Most merchants should never be in this bucket.)

Bucket 1 gets the easy SAQ A. Bucket 2 used to get SAQ A as well — but as of January 2025, most Bucket 2 merchants got moved to SAQ A-EP. Bucket 3 fills out the full SAQ D (~330 questions).

What changed in January 2025

In January 2025, the PCI Security Standards Council clarified the eligibility criteria for SAQ A. The clarification said, in effect: if your website controls the rendering of the page where the cardholder data is entered — even if the actual card form is in a third-party iframe — you no longer qualify for the bare-bones SAQ A.

You qualify for SAQ A only if all of the following are true:

• All payment processing is fully outsourced to a PCI-validated third party.
• Your website does not host the page where card data is entered. (You redirect the customer to the processor’s domain entirely.)
• You receive a Responsibility Matrix from your payment processor that documents who handles which PCI controls.

If you redirect customers to PayPal/Stripe’s hosted checkout pages on *.paypal.com or checkout.stripe.com, you’re still SAQ A. If you keep the customer on your domain and embed an iframe, you’re now SAQ A-EP.

The reason is the rise of Magecart-style attacks. Even if the card form is an iframe served by Stripe, an attacker who compromises a script on your surrounding page can use techniques like overlay injection or DOM manipulation to steal card data. The PCI Council looked at the actual attack surface and said: if your page can be the attack vector, your page is in scope.

When this applies on Shopify

Shopify’s managed checkout — the default checkout on Shopify Payments — is hosted on checkout.shopify.com. The merchant redirects to it. The merchant doesn’t control the rendering. That’s still SAQ A. Shopify covers the script-side controls under their attestation.

Shopify Plus merchants used to be allowed to extensively customize the checkout via checkout.liquid — this absolutely landed them in SAQ A-EP, because they were rendering scripts on the same page where the card was entered. As of August 28, 2025, Shopify killed checkout.liquid and forced all Plus merchants onto Checkout Extensibility (sandboxed JS workers). That move was, in part, designed to pull Shopify Plus merchants back into SAQ A.

You’re in SAQ A-EP on Shopify if:

• You run a headless Shopify storefront. The cart and checkout pages are rendered by your own frontend (Hydrogen, Next.js, whatever), even if the underlying payment is Shopify’s. Your scripts are on the page; you’re SAQ A-EP.
• You use Shopify’s older checkout.liquid and have not yet migrated to Checkout Extensibility (deadline passed; you’re now non-compliant and SAQ A-EP).
• You use a third-party payment app that renders its own checkout flow on your storefront — for example, a “buy now” button that loads a custom checkout in a modal on your product page.

You’re in SAQ A on Shopify if you use Shopify Payments and Shopify’s standard managed checkout, full stop. Most Shopify SMB merchants are here.

When this applies on Stripe

The phrase “I use Stripe” covers at least three different setups, and they have very different SAQ implications.

Stripe Checkout (hosted by Stripe at checkout.stripe.com). Merchant redirects the customer to Stripe’s domain. No card form on the merchant’s site. SAQ A.

Stripe Elements (Stripe’s embeddable card form library). The card input is an iframe served by Stripe — but it’s embedded on the merchant’s domain, surrounded by the merchant’s own HTML and JavaScript. SAQ A-EP since the January 2025 amendment, even though the merchant never sees the card number.

Stripe Payment Intents API with raw card collection. The merchant’s frontend collects the card number directly and POSTs it to Stripe. Almost nobody does this; if you’re doing this you should not be doing this. SAQ D.

Most Stripe merchants are using Stripe Elements. Most of them have not realized they shifted from SAQ A to SAQ A-EP in 2025.

What’s actually different in SAQ A-EP

SAQ A asks roughly:

• Do you keep the third-party processor under contract?
• Is there an attestation of compliance from the processor?
• Are you redirecting customers properly?
• Do you have policies in place?

About 12 questions, mostly about the relationship with your processor.

SAQ A-EP adds:

• Network security — firewalls, segmentation, intrusion detection on the systems that serve your storefront.
• System hardening — vendor defaults removed, only required services running, regular patching.
• Access control — unique IDs, least-privilege, MFA for anyone who can change the storefront code.
• Logging and monitoring — log retention, log review, time synchronization.
• Vulnerability management — quarterly external scans by an Approved Scanning Vendor (ASV), penetration testing.
• Client-side security — script inventory and tamper detection. This is where Requirement 6.4.3 and 11.6.1 live.

About 150 questions. Most of them assume you have at least a part-time security person, which most SMB merchants don’t.

The single biggest practical difference is the client-side controls in 6.4.3 and 11.6.1. Network and system hardening, your hosting provider mostly handles. Access control, your existing admin practices probably cover. ASV scans, you pay $200/year and run them. But “keep an authorized inventory of every JavaScript on your checkout, prove integrity, monitor for changes” is genuinely new work that wasn’t required pre-2025.

How to know which questionnaire you actually owe

Three questions:

1. When the customer enters their card number, what domain shows in the browser address bar?

   • If it’s the processor’s domain — checkout.stripe.com, checkout.shopify.com, *.paypal.com — you’re SAQ A.
   • If it’s your domain — your store name plus a card form embedded somewhere on it — you’re SAQ A-EP (or, in rare cases, SAQ D).

2. Does your site’s JavaScript run on the page where the card form is shown?

   • If yes, even if the card form itself is in an iframe — SAQ A-EP.

3. Did you receive a Responsibility Matrix from your processor?

   The January 2025 amendment requires this for SAQ A. If your processor hasn’t given you one, ask. If they can’t, you can’t claim SAQ A regardless of your setup.

If you’re still unsure, the safest assumption is SAQ A-EP. The penalty for over-attesting (claiming SAQ A when you should have done A-EP) is much worse than the cost of doing A-EP unnecessarily.

What to do if you just realized you’re in A-EP

You owe the rest of the controls now. Most of them are well-trodden — your hosting provider, your CMS, and your processor handle a lot of it. The piece that catches most merchants out is the client-side controls.

The fastest path to a complete answer for 6.4.3 and 11.6.1 is to:

1. Run a free scan of your checkout page. You’ll get the script inventory in 10 seconds.
2. Look at the SRI coverage and CSP status the report flags.
3. Use the remediation list as a punch list.

The free scan won’t give you everything you need to attest, but it gives you the picture in plain English so you can scope the actual work.

If you haven’t started, start now. The alternative is finding out you’ve been quietly out of compliance for a year when your acquirer asks for evidence.

Run a free PCI 6.4.3 scan of your checkout page. Get the script inventory and a one-page PDF report. Try it now →