By E-commerce 4 Internet Marketers Editorial
The PCI Security Standards Council (PCI SSC) published guidance clarifying how e-commerce merchants that embed a third-party payment page or form, typically through one or more iframes, can meet Self-Assessment Questionnaire A (SAQ A) eligibility under PCI DSS v4.0.1. The Council’s February 28, 2025 blog post announcing FAQ 1588 states that the relevant eligibility criterion requires the merchant to have confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).
High-risk merchants often choose hosted fields or Accept.js-style iframes specifically to shrink PCI scope. Misreading SAQ A eligibility after a payment-page script compromise can fail a QSA review and unsettle underwriters who already scrutinize chargeback and fraud files.
What FAQ 1588 says about confirmation
According to the PCI SSC blog summarizing FAQ 1588, merchants can confirm that the merchant webpage is not susceptible to script attacks in either of two ways:
- Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant webpage from scripts targeting account data. Those techniques may be deployed by the merchant or a third party.
- Obtaining confirmation from the merchant’s PCI DSS compliant Third-Party Service Provider (TPSP) or payment processor that provides the embedded payment page or form that, when implemented according to the TPSP or processor instructions, the solution includes techniques that protect the merchant’s payment page from script attacks.
The Council states that this SAQ A eligibility criterion applies to e-commerce merchants whose webpage includes a TPSP or payment processor embedded payment page or form (for example, one or more iframes). It does not apply to merchants that redirect customers entirely away from the merchant webpage to a TPSP (HTTP 30x, meta redirect, or JavaScript redirect), or to merchants that fully outsource payment functions (for example, emailing a link to a TPSP site to pay).
PCI DSS v4.0.1 requirements referenced in the FAQ take effect on April 1, 2025, per the Council’s announcement. Merchants should confirm with their acquirer which SAQ version and effective dates apply to their validation cycle.
Why iframe merchants feel this differently from full redirects
A full redirect or hosted payment page that never loads payment fields on the merchant origin keeps script risk on the processor’s page. An iframe embeds the processor form inside the merchant page. Magecart-style attackers historically inject malicious JavaScript on the parent page to skim data as shoppers interact with nearby fields or to overlay the frame.
That is why SAQ A eligibility for iframe setups still requires a documented confirmation that the merchant site is not susceptible to script attacks, even when card data is supposed to stay inside the processor frame. Industry commentary from assessors and law firms summarizing FAQ 1588 stresses that the eligibility language is broader than a narrow payment-page-only reading, and that merchants should work with TPSPs and acquirers rather than assume historical SAQ A habits still fit.
This explainer does not claim that every Accept.js, hosted-fields, or iframe integration automatically fails SAQ A. It claims that eligibility now hinges on documented script-attack confirmation (merchant/third-party controls aligned with 6.4.3 and 11.6.1, or written TPSP confirmation when implemented per instructions). Merchants who cannot show either path should expect assessors to push them toward a heavier questionnaire such as SAQ A-EP.
What developers should document before the next SAQ
- Inventory every checkout that loads an embedded payment form or hosted field iframe, including WooCommerce, Shopify custom storefronts, and headless carts.
- Ask the payment provider in writing whether their embedded solution includes script-attack protections when installed exactly per current documentation, and retain that confirmation with the SAQ evidence pack.
- If relying on merchant-side controls, document Content Security Policy (CSP), script allowlists, integrity checks, and change-detection practices in the spirit of Requirements 6.4.3 and 11.6.1, including who monitors alerts.
- Separate true redirects (customer leaves the merchant origin) from iframe embeds in architecture diagrams so the acquirer and QSA see which eligibility path applies.
- Align Authorize.Net Accept.js, NMI Collect.js, or similar hosted-field deployments with the vendor’s current implementation guide. Do not invent a hybrid that loads extra scripts the vendor did not authorize.
- Confirm with the acquiring bank which SAQ type they accept for the MID. High-risk underwriting files often ask for the same packet the QSA wants.
Closing
FAQ 1588 clarifies that SAQ A eligibility for iframe and other embedded payment forms depends on confirming the merchant site is not susceptible to script attacks, either through 6.4.3 / 11.6.1-style protections or through documented TPSP confirmation when the embed follows processor instructions. Full redirects and fully outsourced payment flows sit outside that particular criterion. Merchants who chose hosted fields to shrink scope should treat script-attack evidence as part of SAQ readiness, not as optional hardening, before the next assessment or underwriting review.