Which PCI SAQ applies to an iframe or redirect integration?
A full redirect to a hosted payment page or a provider-hosted iframe qualifies for SAQ A. A direct post from the merchant’s own form, or provider JavaScript rendering fields into a merchant-controlled page, requires SAQ A-EP. If the merchant’s server touches the card number, it is SAQ D.
In detail
A full redirect to a hosted payment page or a provider-hosted iframe qualifies for SAQ A. A direct post from the merchant’s own form, or provider JavaScript rendering fields into a merchant-controlled page, requires SAQ A-EP. If the merchant’s server touches the card number, it is SAQ D.
How the PCI SSC draws the lines
SAQ A is for card-not-present merchants that completely outsource all account data functions to PCI DSS validated and compliant third parties. For e-commerce, every element of the payment page delivered to the browser must come only and directly from a compliant provider. SAQ A-EP is for merchants whose site does not receive account data but controls how customers, or their account data, are redirected.
The test assessors use
The question is simple: can the merchant’s own code influence what happens on the payment page? If yes, SAQ A is out. If the merchant’s server receives a card number and forwards it by API, even without storing it, it is SAQ D. After the 2025 update, SAQ A has 27 applicable requirements, against 151 for SAQ A-EP, and SAQ D runs to around 250.
What the 2025 update means for iframes
An iframe integration is still SAQ A, but the merchant must confirm its site is not susceptible to script attacks, and it can rely on a written confirmation from the provider that supplies the iframe. The criterion does not apply to a plain redirect. Offering only a redirect or a fully provider-served iframe keeps every merchant in SAQ A.
More detail in our #PayDecoding episode on PCI DSS SAQ.