SAQ A Changed, E-Commerce Payment Page Risk Did Not
For many e-commerce merchants, the SAQ A has long been viewed as the simplest PCI DSS validation path. The common assumption is merchants only need to assess the applicable PCI DSS requirements listed in the SAQ A. That assumption still holds directionally true but needs more precision.
E-commerce merchants must first confirm they meet the SAQ A eligibility criteria
In 2025, PCI SSC revised SAQ A by removing PCI DSS Requirements 6.4.3, 11.6.1, and 12.3.1 from the list of applicable requirements. At the same time, PCI SSC introduced an eligibility criterion requiring merchants to confirm that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).
Do Merchants Still Need to Address Script-Based Risk
If Requirements 6.4.3, 11.6.1, and 12.3.1 were removed from SAQ A, do SAQ A ecommerce merchants still need to address the risk of script-based attacks?
Yes.
Merchants still need to confirm SAQ A eligibility which now includes the statement:
“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
PCI SSC FAQ 1588 clarifies that this eligibility criterion only applies specifically to e-commerce merchants using a third-party service provider (TPSP) embedded payment page or form (e.g., inline frame or/iframe).
It does not apply to:
- Merchants that redirect customers to a TPSP website (e.g., HTTP redirect, meta redirect, JavaScript redirect)
- Merchants that fully outsource payment functions (e.g., customers pay directly on the TPSP site via a link)
How to Confirm a Site is Not Susceptible to Script-Base Attacks
For merchants using an embedded payment page or/form, PCI SSC identifies two primary approaches to confirming that the merchant webpage is not susceptible to script attacks:
1. Implement Technical Controls
Merchants may implement controls similar to those described in Requirements 6.4.3 and 11.6.1 to protect the payment page.
Examples include:
- Webpage monitoring
- Proxy-based or other authorization methods
- Content Security Policy (CSP)
- Sub-resource integrity (SRI)
These controls help ensure scripts are authorized, maintain integrity, and are monitored for tampering.
2. Obtain TPSP Confirmation
Merchants may obtain written confirmation from a PCI DSS compliant TPSP or payment processor that the embedded payment solution includes protections against script-based attacks when implemented as instructed.
This confirmation may take the form of:
- An Attestation of Compliance (AOC)
- Contractual language
- Product documentation or implementation guides
- Ad hoc communications or other written documentation
The practical question is no longer only, “Did the merchant answer Requirements 6.4.3 and 11.6.1 in SAQ A?” The better question is, “Can the merchant support SAQ A eligibility and show how the embedded payment implementation addresses script-based risk?”
What PCI DSS Does Not Require
The revised SAQ A does not require every SAQ A merchant to assess Requirements 6.4.3, 11.6.1, and 12.3.1.
Additionally, not all third-party script providers are considered TPSPs for SAQ A purposes. PCI SSC FAQ 1592 clarifies that a third-party script provider is not a TPSP if:
- The scripts are unrelated to payment processing, and
- The scripts cannot impact the security of cardholder data or sensitive authentication data
Why This Misconception Exists
The confusion is understandable. When requirements are removed from SAQ A, it can appear as though security responsibilities have been reduced. However, that interpretation is too broad.
When using embedded payment implementations, the merchant webpage remains in scope, even if payment data is processed by a TPSP or payment processor.
The misconception also stems from how iframe payment models are described. Business teams may view these models (e.g., the iframe) as fully outsourced since the merchant does not directly receive or transmit credit card data, while security and compliance teams must still understand:
- What scripts run on the merchant webpage
- Whether those scripts can affect the payment system
PCI SSC’s guidance explains that Requirements 6.4.3 and 11.6.1 were introduced to reduce e-skimming risk by ensuring payment page scripts are being authorized, checked for integrity, and monitored for tampering. The risk remains relevant regardlessof changes to SAQ A reporting.
Common Pitfalls for SAQ A
Treating SAQ A Removal as Risk Removal
The removal of requirements from SAQ A does not eliminate the underlying e-commerce attack surface.
Relying Only on a TPSP AOC
A TPSP AOC may not explain how the merchant’s specific implementation addresses script-based risk.
Not Distinguishing Redirect from Embedded Payment Forms
FAQ 1588 applies differently depending on whether payment is embedded or redirected.
Waiting Until PCI DSS Submission to Ask the TPSP
Obtaining confirmation from TPSPs often requires coordination across multiple teams and can take time. For example, legal, security, vendor management, and payment operations teams may need to review the request.
Bottom Line
SAQ A changed how e-commerce demonstrates compliance, not what they must protect against it.
Merchants using SAQ A must still:
- Confirm they meet eligibility criteria
- Maintain evidence supporting their payment model
For redirect and fully outsourced payment flows, evidence should show that account data is only entered in the TPSP or payment processor environment. For embedded payment forms, merchants should be prepared to demonstrate how the script-based risks are addressed, even though specific requirements (such as 6.4.3 and 11.6.1) are no longer explicitly addressed in SAQ A.
Tevora Can Help
Tevora’s experienced PCI DSS advisors can answer questions about SAQ A, e-commerce payment flows, TPSP responsibilities, and payment-page evidence. We welcome the opportunity to help you meet PCI DSS compliance standards and prepare for validation with greater clarity.
To discuss your PCI DSS needs, call Tevora at (833) 292-1609 or email [email protected]
