SAQ A vs SAQ A-EP: What's the Difference and Which Do You Need?

Two Self-Assessment Questionnaires cover UK online businesses that never handle card data on their own systems: SAQ A and SAQ A-EP. The names are nearly identical; the workload is not. SAQ A runs to around 30 questions, SAQ A-EP to roughly 190 — plus quarterly security scans — and which one applies to you is decided by a technical detail of your checkout that most business owners have never had a reason to inspect. This guide explains that detail in plain English, with examples, so you can work out where you stand. For the wider background on how SAQs fit into PCI DSS, see our complete PCI DSS compliance guide.

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

Both questionnaires are for e-commerce merchants who have outsourced payment processing, and in both cases the card number never touches the merchant's own server. The difference is who delivers the payment page to your customer's browser.

With SAQ A, the whole payment experience comes from your payment provider. Either the customer is redirected to a page the provider hosts, or every card field on your checkout sits inside an iframe the provider serves. Your website hands the customer over and receives them back — nothing more.

With SAQ A-EP, your website does not receive card data either, but it affects how the payment is captured. The classic example is a direct-post integration: your own site serves the payment form, and when the customer presses pay, their browser sends the card details straight to the gateway. Another is a JavaScript or API integration where the card fields are created by your page's own code before the details are tokenised and sent on. In both cases, someone who compromises your website could tamper with the form or its scripts and skim card details — even though your server never sees a card number. That risk is why the card brands treat A-EP merchants so differently.

Why is SAQ A-EP so much bigger?

Because your web server is now part of the security picture, SAQ A-EP pulls in large parts of PCI DSS that SAQ A skips entirely: secure software development and change control, patching, logging and monitoring, access control across your systems, penetration testing, and quarterly external vulnerability scans carried out by an Approved Scanning Vendor (ASV). The result is roughly 190 questions against SAQ A's 30 or so — and, more importantly, real ongoing obligations rather than a once-a-year form. For a small business, A-EP is not a weekend job; it usually means developer time, a scanning subscription and evidence-keeping through the year.

How does your checkout integration decide which SAQ you need?

The mapping is fairly mechanical once you know what your site does:

• Full redirect to the provider's payment page (the browser address changes to the provider's domain) — SAQ A.
• Provider-hosted iframe, where every card field is inside a frame served from the provider's domain — SAQ A.
• A hosted platform checkout, such as Shopify's own checkout on a standard plan — typically SAQ A, because the platform delivers the payment page for you.
• Direct post: your site serves the payment form and the customer's browser posts card data straight to the gateway — SAQ A-EP.
• JavaScript or client-side API integrations where the card fields are created by your own page — SAQ A-EP.
• Card data actually reaching or being stored on your own server — neither: that is SAQ D. See SAQ A vs SAQ D for that comparison.

One warning: a single stray form field can change the answer. Collecting the cardholder's name and billing address on your own page is fine — but if any field that captures actual card data is served by your site rather than the provider, you are not on SAQ A. Where an integration mixes elements, your provider's own documentation normally states which SAQ each integration method supports; treat that as your starting point rather than guessing.

What do the two SAQs cost in time and money?

SAQ A is a few hours of work once your evidence is together. SAQ A-EP is a different order of magnitude: reading and answering roughly 190 questions, fixing the gaps they reveal, arranging quarterly ASV scans and keeping them passing, and maintaining documentation all year round.

A worked example makes the gap concrete. Suppose a developer or IT contractor charges £40 an hour. If SAQ A-EP takes 20 hours of technical work in the first year — a conservative figure where remediation is needed — that is £800 before you have paid for scans or for anyone's time completing the form itself. Re-integrating your checkout to use the provider's hosted page or iframes might take that same developer a day or two, say £300 to £600 as a one-off — after which you qualify for SAQ A and the ongoing burden largely disappears. For many small merchants, changing the integration is cheaper than complying with A-EP even once.

There is also the cost of getting it wrong. Merchants who discover they are on A-EP sometimes stall, and an unvalidated status typically attracts a non-compliance fee of £5 to £25 a month — £180 a year at £15. Our breakdown of PCI compliance costs in the UK covers the wider numbers, and a fully managed service like Fraud Defence First's completes and files the correct SAQ for a flat £100 + VAT a year, whichever type you turn out to need.

How do you check what your site actually does?

You do not need to be technical to get a reliable answer. Work down this list:

• Watch the address bar. Go through your own checkout and stop before paying. If the browser moves to your provider's domain for the card step, you have a redirect — SAQ A territory.
• Inspect a card field. Right-click the card number box and choose 'Inspect'. If the field sits inside an iframe loaded from your provider's domain, it is provider-hosted. Every card field must be.
• Ask your developer or agency one question: is our checkout a redirect, hosted iframe or hosted fields, direct post, or a client-side API integration? Those words map directly onto SAQ types.
• Ask your payment provider. Gateways publish which SAQ each of their integration methods supports — and their answer is the one your acquirer will expect to see.

Do not experiment with real card numbers to see where the data goes — your provider or developer can confirm the integration type without a live transaction.

Can you switch from SAQ A-EP to SAQ A?

Yes, and it is often the smartest long-term move. Most gateways offer a hosted page or hosted-fields version of the same service, so switching rarely means changing provider — it means changing integration method. Once every element of the payment page is delivered by the provider, you meet the SAQ A eligibility criteria at your next annual validation, and the scans and extra questions fall away. Our guide to PCI compliance for e-commerce businesses walks through the checkout options in more detail.

Key takeaways

• SAQ A and SAQ A-EP both cover e-commerce merchants who never touch card data — the difference is who serves the payment page.
• Redirects and provider iframes point to SAQ A; direct-post and client-side API integrations point to SAQ A-EP.
• A-EP is roughly 190 questions with quarterly ASV scans; A is around 30 questions with neither.
• Check your integration via the address bar, an iframe inspection, your developer, or your provider's documentation.
• If you land on A-EP, re-integrating to a hosted checkout is often cheaper than complying — and moves you back to SAQ A.