PCI DSS 4.0 SAQ-A changes: what ecommerce merchants need to know

The Self-Assessment Questionnaire A (SAQ-A) is the simplest PCI DSS compliance path. It was designed for merchants who fully outsource payment processing and never touch card data themselves. For years, many ecommerce stores used SAQ-A as their compliance vehicle. PCI DSS 4.0 changed that.

The new requirements tightened SAQ-A eligibility criteria and introduced script management obligations that caught many merchants off guard. If you previously used SAQ-A and have not reviewed your eligibility since March 2025, you may no longer qualify.

What SAQ-A is and who it was designed for

SAQ-A is a self-assessment form for merchants who meet a specific set of criteria. The core premise is that a merchant has fully outsourced all cardholder data functions to third-party service providers. The merchant's own systems never see, store, process or transmit card data.

In practice, SAQ-A was commonly used by ecommerce merchants who:

• Redirect customers to a payment processor's hosted page to enter card details (PayPal, Stripe Checkout, Shopify Payments hosted checkout).
• Use an iframe hosted by their payment processor that loads within their own checkout page.
• Have no contact with raw card numbers at any point in the transaction.

SAQ-A has 22 requirements compared to SAQ-D's 329. The difference in compliance burden is significant. That gap explains why merchants were eager to maintain SAQ-A eligibility.

What changed in PCI DSS 4.0

PCI DSS 4.0, finalized in March 2022 and mandatory since March 2025, added two requirements that affect SAQ-A merchants directly. The full PCI DSS 4.0 compliance timeline covers every key date and transition milestone.

First, the SAQ-A eligibility criteria were tightened. Under v3.2.1, the criterion was simply that "all payment processing is entirely outsourced." Under v4.0, the language became more specific: the merchant's website must not receive cardholder data and the merchant must have confirmed that the third-party payment processor is PCI DSS compliant.

Second, and more significantly, the new SAQ-A added requirements around script management. Merchants that use payment iframes embedded on their own pages (rather than a full redirect) must now:

• Maintain an inventory of all scripts on pages that contain the payment iframe.
• Confirm that each script is authorized and necessary.
• Implement change and tamper detection for those pages.

These are essentially requirements 6.4.3 and 11.6.1 applied to the iframe use case. The PCI SSC recognized that even if card data never leaves the iframe, malicious JavaScript on the parent page could still capture keystrokes or manipulate the iframe's behavior.

The iframe controversy

The inclusion of script management requirements in SAQ-A generated significant debate within the payments industry. The argument for including them was straightforward: an iframe on a page full of uncontrolled third-party scripts is not truly isolated. JavaScript on the parent page can overlay the iframe with a fake form, capture input events or redirect the iframe source.

The argument against was equally clear: requiring script management for every merchant that uses Stripe Elements or Braintree Hosted Fields would impose enterprise-level obligations on small merchants who have no ability to detect or prevent supply-chain attacks on their analytics vendors.

Visa published a FAQ in March 2025 that clarified the PCI SSC's position. Visa confirmed that iframe-based integrations where the merchant has JavaScript on the payment page are in scope for script management requirements. Merchants who use a full redirect (customer leaves the merchant's site entirely to complete payment) retain the simpler SAQ-A eligibility without script management obligations.

SAQ-A vs SAQ-A-EP: which applies to you

SAQ-A-EP (the "EP" stands for "e-commerce with partially outsourced") was introduced to cover merchants who use a redirect to a hosted payment page but where the merchant's website still hosts the payment page entry point. It has always had more requirements than SAQ-A.

After PCI DSS 4.0, the distinction between SAQ-A and SAQ-A-EP is primarily about whether you use a redirect or an iframe:

• Full redirect (SAQ-A). The customer clicks "checkout" and is sent to your payment processor's domain. They enter card details on the processor's page. They are returned to your store after payment. Your checkout page has no scripts that run during the payment entry step because the customer is not on your page.
• Iframe on your page (SAQ-A or SAQ-A-EP with script requirements). Your checkout page loads, with the card entry form provided by a processor iframe. Scripts on your page run while the customer enters card details. This triggers script management requirements under v4.0.
• JavaScript tokenization on your page (SAQ-A-EP). You load a JavaScript library from your processor (like Stripe.js) that runs on your page and tokenizes card data in the browser before sending it to your server. This has always required SAQ-A-EP.

SAQ-A-EP has 193 requirements. If your integration moved you from SAQ-A to SAQ-A-EP, the compliance work multiplies significantly.

Impact on Shopify, BigCommerce and hosted checkout merchants

The impact depends heavily on how your checkout is configured:

• Shopify Plus with Shopify Payments. Shopify handles checkout on its own subdomain (checkout.shopify.com) for standard plans. Merchants do not control that page's scripts. Shopify maintains PCI DSS compliance for the checkout flow. Merchants are responsible for their own theme scripts on cart pages and for any custom checkout scripts added via Shopify Functions or checkout extensions.
• Shopify with third-party payment gateways. If you redirect to a third-party processor, you may retain SAQ-A eligibility depending on your integration. If you embed a payment form directly in your Shopify theme, you likely fall under the new script management requirements.
• BigCommerce. BigCommerce hosts the checkout on its own infrastructure. Merchants using standard payment integrations that redirect to hosted pages have limited exposure. Custom checkout implementations using BigCommerce's Stencil checkout and direct payment SDKs require careful review.
• WooCommerce. WooCommerce runs on your own hosting. You have full control over what scripts load on checkout pages, which means you have full responsibility. Most WooCommerce stores use gateway plugins that either redirect (PayPal Standard, some Stripe modes) or embed payment fields on the page. If you embed, you need script management.
• Magento / Adobe Commerce. Similar to WooCommerce: full merchant responsibility. Magento ships with Braintree and PayPal integrations. The Braintree Hosted Fields integration (which many merchants use) loads a JavaScript SDK on your checkout page and uses iframes for card entry. This falls under the new requirements.

Practical steps to maintain or verify SAQ-A eligibility

Start by documenting exactly how your payment integration works. Draw the data flow from the customer clicking "pay" to the payment being processed. Identify every point where your page has JavaScript running during the card entry step.

• Audit your checkout pages. Load your checkout in a browser with developer tools open. Check the Network tab for all scripts that load. Check the Console for third-party script activity. Count how many scripts run on the page where card details are entered.
• Review your integration type. Confirm with your payment processor whether your integration type is full redirect, iframe or JavaScript tokenization. Ask them directly: "Does our current integration require SAQ-A or SAQ-A-EP under PCI DSS 4.0?"
• Consider switching to a full redirect if you currently use an iframe. Moving from Stripe Elements (iframe on your page) to Stripe Checkout (full redirect to Stripe's hosted page) reduces your script management obligations substantially. Our guide to hosted payment pages and PCI compliance explains the tradeoffs between integration types. There is a conversion rate tradeoff: hosted payment pages typically convert 5-15% lower than embedded payment forms, but that must be weighed against the compliance cost.
• If you use an iframe, implement script management. Build or buy a script inventory. Implement Content Security Policy on checkout pages. Set up automated weekly monitoring for script changes. Document your authorization process for adding new scripts.
• Verify your payment processor's PCI DSS compliance. The new SAQ-A explicitly requires you to confirm that your processor is PCI DSS compliant. Ask them for their current Attestation of Compliance (AOC). This is a document your processor should provide on request.
• Work with a QSA if uncertain. If you are not confident about your eligibility, engage a Qualified Security Assessor. A QSA consultation to determine your appropriate SAQ typically costs $1,500 to $5,000. That is far cheaper than completing the wrong SAQ and facing a breach with inappropriate controls.

What happens if you use the wrong SAQ

Filing the wrong SAQ is a compliance failure. If a breach occurs and an investigation reveals you were using SAQ-A when your integration required SAQ-A-EP or SAQ-D, your acquiring bank will hold you liable for the full cost of the breach investigation, card reissuance costs and any fraudulent transactions.

Forensic investigations following a card data breach typically cost $50,000 to $500,000. That does not include fines from card brands, which can reach $500,000 per incident. For a mid-market ecommerce store, that is an existential financial event.

The goal of SAQ-A eligibility should not be to minimize compliance paperwork. It should be to accurately reflect your security posture and ensure the right controls are in place. For the full picture of what securing your checkout involves, see our payment page security guide.

The bottom line

PCI DSS 4.0 made SAQ-A more restrictive, not less. If your checkout loads third-party scripts on the same page where an iframe handles card entry, you have new obligations. The safest path is to audit your checkout scripts, understand your integration type and verify your eligibility with your payment processor or a QSA.

Many mid-market ecommerce stores are using SAQ-A when they should be using SAQ-A-EP. Most do not know this until an incident forces the question.

Frequently asked questions

What changed in SAQ-A under PCI DSS 4.0?

PCI DSS 4.0 tightened SAQ-A eligibility and added script management requirements. Merchants using payment iframes must now inventory all scripts on the checkout page, authorize each one and implement tamper detection.

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

SAQ-A has 22 requirements and applies to merchants who fully outsource payment processing. SAQ-A-EP has 193 requirements and applies to merchants whose website directly affects payment security, such as those using JavaScript tokenization.

Do I still qualify for SAQ-A if I use Stripe Elements?

You may qualify for SAQ-A with additional script management requirements under PCI DSS 4.0. Because Stripe Elements uses iframes on your checkout page, you must inventory and monitor all other scripts on that page.

What happens if I use the wrong SAQ?

Filing the wrong SAQ is a compliance failure. If a breach occurs and investigation reveals you were using SAQ-A when SAQ-A-EP was required, your acquiring bank will hold you liable for the full cost of the breach investigation and fraudulent transactions.