- The differences between SAQ A and SAQ A-EP compliance categories
- Iframes explained
- Your options for simplified PCI DSS compliance
We often get questions from payments leaders, security and compliance officers and business owners about the difference between SAQ A and SAQ A-EP regarding the integration of web checkout forms. This isn’t altogether surprising since there is much misinformation out there, and there are various ways to integrate checkout forms, which have a bearing on which category you are eligible for.
SAQ A applies to online merchants that outsource all responsibility of cardholder data to a third party. In contrast, SAQ A-EP applies to online merchants that don’t receive cardholder data but control how cardholder data is redirected to a PCI DSS validated third-party such as a payment processor or orchestrator.
To put this into context: if a merchant’s e-commerce website is configured to entirely redirect customers to a compliant third-party website before requesting cardholder data, or if an iframe provided by a compliant third-party provider is used for the collection of cardholder data, the flow of cardholder data is controlled by the third-party provider, and the merchant will qualify for the SAQ A category.
An iframe, sometimes called an inline frame, is an HTML element that loads another webpage within the parent page. When the web browser encounters an iframe element, it takes the code from the referenced src and loads it as its website that is then put entirely within the browsing page. It’s called an inline frame because it all looks and feels like one web page to the user.
Below is an example of the HTML of a merchant’s checkout page where they are using iframes to collect cardholder data such as the card number and the CVV. As the two iframes delivered to the consumer’s browser originate only and are directly from a third-party(pay.datatrans.com), sensitive data will never touch a merchant’s server. This means that the merchant can provide a customised and seamless checkout experience for their customers without implementing pre-designed payment pages or redirect customers to another page. On top of that, because sensitive card data never touches the merchant’s server, it keeps the merchant within the SAQ A requirements category.
At present, a merchant implementing an e-commerce solution that uses iframes to load all payment content from a PCI DSS compliant service provider may be eligible to assess its compliance using a reduced list of controls identified in SAQ A, the smallest possible subset of PCI DSS requirements, because most of the PCI DSS requirements are outsourced to the PSP.
PCI DSS Special Interest Group, “Best Practices for Security E-Commerce” (April 2017) p. 12
For merchants who are seeking advice on their PCI DSS compliance requirements, please get in touch with us free of charge to discuss your options in more detail.