With the PCI Council’s April 2025 guidance on e-skimming (Requirements 6.4.3 & 11.6.1), it’s clear that even with a PSP-controlled iframe, a merchant’s parent page can remain in scope. Here’s how our team helps organizations understand the difference between SAQ-A and SAQ-A-EP and strengthen client-side defenses.
We’ve worked with hundreds of e-commerce environments where merchants believed they were “SAQ-A eligible,” only to discover their implementation placed them in SAQ-A-EP territory. The difference is critical — not only for scoping but also for the security and compliance controls required.
| Aspect | SAQ-A | SAQ-A-EP |
|---|---|---|
| Intended For | Merchants who completely outsource all payment functions to PCI DSS–validated providers. | Merchants who outsource payment processing but host the payment page or load scripts that can impact cardholder data capture. |
| Cardholder Data Exposure | No CHD storage, processing, or transmission by the merchant. | Merchant systems do not process CHD but can affect its security through hosted pages or scripts. |
| Payment Page Hosting | Redirect to or fully PSP-hosted iframe (no merchant code control). | Merchant-hosted page with PSP iframe or JavaScript integration. |
| PCI DSS Requirements | ~22 requirements (limited to policy and service-provider management). | ~139 requirements (includes vulnerability management, patching, monitoring, and client-side script integrity). |
| Web Server Scope | Out of scope for CHD; cannot alter payment data flow. | In scope — compromise could alter scripts or redirect CHD. |
| Risk Profile | Low — minimal attack surface. | Moderate to high — merchant site could be targeted for e-skimming. |
SAQ-A is designed for merchants that fully outsource all cardholder-data functions to a PCI DSS–validated payment service provider (PSP). The merchant’s website neither hosts nor controls any part of the payment form or its scripts. Customers either leave the site to a hosted checkout or view a PSP-controlled iframe that the merchant cannot alter or inject code into.
In other words, the iframe may be PSP-controlled, but the parent page that embeds it is still subject to PCI DSS scrutiny if any scripts or configurations could affect the payment page’s behavior or integrity.
Merchants fall into SAQ-A-EP when their website hosts or influences the payment form in any way — for instance, by loading analytics, chat widgets, tag managers, or operating as a single-page application whose JavaScript persists through checkout. Even though card data still flows directly to the PSP, the merchant’s environment can impact its security and is therefore in scope for a larger control set.
Today’s e-commerce sites rely heavily on third-party scripts for analytics, personalization, and marketing — each of which can become an attack vector. The PCI SSC document highlights how Magecart and other e-skimming threats operate through silent or overlay-style attacks, emphasizing the importance of proactive script monitoring.
At Intersec Worldwide, we partner with Source Defense — a SaaS platform purpose-built for client-side monitoring and control. This partnership enables us to help clients meet Requirements 6.4.3 and 11.6.1 by:
Based on the continuing rise in successful e-commerce breaches and the ongoing confusion around the subtleties of SAQ-A versus SAQ-A-EP eligibility, our team at Intersec Worldwide believes that the industry is moving toward a single expectation for all online merchants. In practice, this will likely mean that all e-commerce merchants will be required to validate against the SAQ-A-EP—regardless of whether they rely on redirects, hosted payment pages, or PSP-controlled inline frames.
This shift makes sense. Attackers are no longer targeting only payment processors; they compromise merchant-side code through analytics scripts, tag managers, and CMS plugins. From a risk standpoint, the distinction between “hosted” and “embedded” has eroded. The merchant website still presents a potential pathway to the consumer’s browser, where card data is entered.
For that reason, we anticipate that future iterations of PCI DSS—or brand-level enforcement—will expand SAQ-A-EP applicability to virtually all merchants offering browser-based payments. Preparing for that now means establishing client-side monitoring, change detection, and robust script governance as part of your baseline e-commerce security program rather than waiting for compliance to force it.
Our team helps merchants and service providers identify the correct SAQ (A vs. A-EP), implement PCI DSS 6.4.3 & 11.6.1 controls, and deploy Source Defense for client-side protection.
Email Intersec Worldwide Visit intersecworldwide.com
Disclaimer: The views expressed in this article are those of the Intersec Worldwide team and do not necessarily represent the views or policies of the PCI Security Standards Council. PCI DSS and related materials are the property of the PCI SSC and are referenced solely for educational purposes. Mention of third-party products or services (such as Source Defense) does not imply PCI SSC endorsement.
© 2026 Intersec Worldwide. All rights reserved.