Why This Matters

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.

Key Distinction: SAQ-A vs. SAQ-A-EP

What SAQ-A Really Means

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.

The Inline iFrame Nuance

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.

When You’re in SAQ-A-EP

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.

Key Additions in the 2025 Guidance

• Requirement 6.4.3 — Script governance: Every payment-page script must be authorized, integrity-verified, and listed with business or technical justification (CSP, SRI, hashing, or proxy verification can support this).
• Requirement 11.6.1 — Tamper detection: Merchants must detect unauthorized changes to security-impacting HTTP headers and script content as rendered in the customer’s browser, at least weekly or per a targeted risk analysis.
• Approved methods: Webpage monitoring and proxy-based solutions are specifically called out by PCI SSC as effective approaches.

Modern E-Skimming Threats

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.

How Intersec + Source Defense Help

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:

• Maintaining a live inventory of executing scripts and domains
• Verifying authorization and integrity against defined baselines
• Detecting unauthorized additions, deletions, or modifications to scripts and headers
• Alerting in real time and blocking malicious behavior

Practical Next Steps

• Map your architecture: Identify who controls each element of your payment page.
• Validate iframe implementations: Ensure the iframe is fully PSP-hosted and your parent page cannot influence it.
• Implement 6.4.3: Maintain a script inventory, authorization workflow, and integrity checks via CSP, SRI, or proxy-based tooling.
• Implement 11.6.1: Deploy webpage monitoring or proxy-based tamper detection; set frequency; link alerts to your incident response plan.
• Validate with a QSA: Confirm your SAQ type and required evidence before attestation.

Looking Ahead: The Future of SAQ Eligibility

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.