Does an iframe always keep a merchant in SAQ A?
Only if every element of the payment page comes only and directly from a PCI DSS validated provider, and the merchant does not store, process or transmit card data. The merchant must also confirm its site is not susceptible to script attacks. If its own page hosts the form fields through direct post or JavaScript, it moves to SAQ A-EP.
In detail
Only if every element of the payment page comes only and directly from a PCI DSS validated provider, and the merchant does not store, process or transmit card data. The merchant must also confirm its site is not susceptible to script attacks. If its own page hosts the form fields through direct post or JavaScript, it moves to SAQ A-EP.
The conditions
SAQ A applies to e-commerce merchants that fully outsource payment handling. For an iframe to keep a merchant there, every element of the payment page must come only and directly from a PCI DSS validated provider, and the merchant must not store, process or transmit card data on its own systems. Since PCI DSS v4.0, the merchant must also confirm that its site is not susceptible to script attacks that could affect the payment page.
What moves a merchant to SAQ A-EP
- Hosting the form fields on its own page, even if card data is posted directly to the provider.
- JavaScript on the merchant's page that creates or handles the card fields.
- Any element of the payment page served from the merchant's own servers.
What operators should check
How each merchant integrates: a full redirect or a hosted page keeps them in SAQ A; an iframe from the provider usually does; hosted fields or direct post do not. The integration method should be recorded on the merchant file with the SAQ type, and reviewed when the merchant changes it. A provider that offers a hosted page the merchant can style removes the main reason merchants build their own payment form.