PCI SAQ A vs SAQ A-EP: Which Applies to Your Website After January 2025?

PCI SAQ A is the Self-Assessment Questionnaire for merchants that fully outsource card payments, and since January 2025 it carries a new eligibility criterion: if your site embeds the provider’s payment form, you must confirm your website is not susceptible to attacks from scripts that could affect your e-commerce systems. SAQ A applies when every element of your online payment page comes directly from a PCI DSS compliant provider, through a redirect or a provider-hosted iframe. SAQ A-EP applies when your own website serves the payment form or scripts that handle it, even if card data goes straight to the provider. The difference decides whether you complete a short questionnaire or one several times longer.

This guide explains SAQ A eligibility under PCI DSS v4.0.1, what the January 2025 change means in practice, how SAQ A differs from SAQ A-EP, and how to move from SAQ A-EP to SAQ A if your checkout allows it. If you would rather answer a few questions first, our free PCI compliance check suggests your likely SAQ.

Key takeaways

• Both SAQs are for e-commerce merchants that do not store, process or transmit card data on their own systems.
• SAQ A needs every element of the payment page to come from the provider.
• SAQ A-EP applies when your site delivers the form or scripts, even with no card data on your servers.
• SAQ A merchants that embed a provider’s iframe must now confirm their site is not susceptible to script attacks.
• A redirect or provider-hosted iframe is often the simplest way to cut PCI DSS effort.

What is PCI SAQ A?

SAQ A is the Self-Assessment Questionnaire for card-not-present merchants (e-commerce, or mail and telephone order) that have fully outsourced all account data functions to PCI DSS compliant third parties. Online, the key criterion is that all elements of the payment page delivered to the customer’s browser come only and directly from a compliant provider. That usually means:

• A URL redirect to the provider’s hosted payment page.
• An iframe in which the provider serves the whole payment form, including “hosted fields” where each card field is its own provider-served iframe.

The current versions of both questionnaires, with the exact wording of their eligibility criteria, are in the PCI SSC document library.

What is SAQ A-EP?

SAQ A-EP is for e-commerce merchants that outsource payment processing but whose website affects the security of the transaction. Your servers never receive card data, but your site delivers the form, or scripts that handle it, to the customer’s browser. If card data does pass through your own servers, neither SAQ applies and you complete SAQ D. Typical integrations are:

• Direct post: a form on your page posts card data straight to the provider.
• Merchant-served JavaScript: your page builds or controls the payment form, and card data is sent to the provider from the browser.

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

Why does the website matter so much?

Digital skimming works by altering the payment page in the customer’s browser. If an attacker compromises your web server, content management system or a third-party script your site loads, they can change a form or inject code that copies card details as they are typed.

With a redirect or provider-hosted iframe, the form is served from the provider’s systems, so a compromise of your site cannot change it directly. An attacker could still try to send customers to a fake page or overlay the iframe, which is why SAQ A now asks about script attacks. With direct post or a merchant-served form, your site is part of the payment process and must be secured to a much higher standard.

What changed in SAQ A in January 2025?

When PCI DSS v4.0 introduced Requirements 6.4.3 (managing payment page scripts) and 11.6.1 (detecting changes to payment pages), they initially appeared in SAQ A. On 30 January 2025 the PCI SSC announced a revised SAQ A that removes both, along with Requirement 12.3.1, the targeted risk analysis that supported 11.6.1. In their place is a new eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The revised questionnaire replaced the October 2024 version on 31 March 2025.

On 28 February 2025 the Council published FAQ 1588 to explain the criterion. It applies to merchants whose web page embeds a payment page or form from a provider, such as an iframe, and not to merchants that redirect customers to the provider’s payment page.

If the criterion applies to you and you cannot make that confirmation, you are not eligible for SAQ A. Either way, the scripts on the page that hosts or links to your payment form still matter to your customers’ security.

How do I confirm my site is not susceptible to script attacks?

FAQ 1588 describes two routes: apply techniques like those in 6.4.3 and 11.6.1 yourself or through a provider, or obtain confirmation from your payment provider that its embedded payment solution includes protection against script attacks. In practice:

• Know which scripts run on the pages that host the iframe or link to the payment page.
• Remove scripts you do not need, and control who can add new ones, including marketing tags.
• Ask your payment provider what protection its embedded form includes, and keep its written confirmation.
• Consider a Content Security Policy to restrict what scripts can load and where the page can be framed.
• Record what you checked and when, so you can show how you reached your confirmation.

What does SAQ A-EP require?

SAQ A-EP covers most of the 12 principal requirements for your web environment, including:

• Network security controls and secure configuration of all web-facing systems.
• Secure development, change control and protection of public-facing web applications.
• Payment page script management and change detection (6.4.3 and 11.6.1).
• Logging and log review, and MFA for administrative access.
• External vulnerability scanning by an ASV, and external penetration testing (plus segmentation testing if you use segmentation to reduce scope).
• Security policies, risk analysis, training and incident response.

In practice, plan for quarterly ASV scans of your web environment, delivered through our PCI SSC Approved Scanning Vendor partner, and annual PCI DSS penetration testing of your checkout and the systems behind it. A web application penetration test of the checkout is the core of that work, and website penetration testing also covers your shop platform, its plugins and the admin area. For a small online business, the gap between A and A-EP can mean the difference between a few days of work and an ongoing security programme.

How do I move from SAQ A-EP to SAQ A?

Switching to a redirect or provider-hosted iframe is often the most effective change an online merchant can make. Most providers offer hosted options that can be styled to match your site, so the effect on customers is usually small.

1. Check the provider’s integration options. Confirm the hosted page or iframe is covered by its PCI DSS Attestation of Compliance.
2. Map every payment route. Make sure no other channel, such as a legacy checkout, a mobile app or phone orders keyed into your own systems, keeps you in a higher scope.
3. Review the hosting pages. Reduce and control the scripts on the pages that host or link to the payment form.
4. Document the new flow and keep evidence for your script-attack confirmation.
5. Confirm with your acquirer or a QSA that SAQ A now applies.

Our guide to which PCI SAQ you need covers the other questionnaires if you also take payments in person or by phone, and our guide on how to fill out a PCI SAQ lists the errors we see once merchants make the switch. If phone orders are part of the mix, see our guide to taking card payments over the phone.

How Sovereign Secure can help

Choosing between SAQ A and SAQ A-EP is the first compliance decision for any online merchant. As a PCI SSC-approved QSA company, our PCI DSS consultancy can review your checkout integration, confirm which SAQ applies and help you complete it, and our PCI compliance audit service covers merchants whose acquirer asks for a QSA.