- 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.
E-commerce merchants who use other technologies or processes, such as JavaScript widgets or Direct Post methods, to direct the flow of cardholder data from the customer directly to the compliant third-party provider would be in the SAQ A-EP 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.
Until now, there was a widely held misconception that the JavaScript that creates the iframes would correspond to the “JavaScript Form” described on page 15 of the “Best Practices for Securing E-commerce” guide. The above-mentioned JavaScript (highlighted red in the previous image) does not load any payment form elements but only initialises the creation of the iframe. These iframes are resistant to the theft of cardholder data as the cardholder enters it since none of the elements for the payment page originates from the merchant’s website. As the quote below demonstrates, this approach qualifies merchants for the SAQ A 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
Merchants and QSAs often receive conflicting advice from PSPs which can be incredibly confusing when the difference between using an iframe and embedding a payment form into your webpage appears to be minimal. However, the difference in security is substantial: payment pages loaded into an iframe are resistant to the transparent theft of cardholder data as the consumer enters it; techniques such as Direct Post and JavaScript forms are not.
This explains why the PCI Security Standards Council has differentiated the two types of setup, and why SAQ A requirements apply to the use of iframes or payment page redirects, not embedded JavaScript forms and Direct Posts. It is also great to see that PCI DSS v4.0 provides much clearer guidance when it comes to the integration of iframes. However, remember that not all iframe solutions out there may meet the criteria for SAQ A, so it’s worth checking against the SAQ A criteria.
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.
.svg)
