.svg){kind=icon}
SAQ A vs. A-EP: What E-Commerce Merchants, Service Providers Need to Know Now
Date published:
Jan 10, 2022
.svg)
Taking a firm stance on the security of partially outsourced e-commerce sites.
When the new PCI DSS version 3.0 Self Assessment Questionnaires (SAQs) were released earlier this year, my colleagues and I closely read them to understand the potential impact on self-assessing merchants as well as the merchant service providers ControlScan partners with. At the time, the Council did not include any supporting guidance documentation, but upon examination of the SAQ A and SAQ A-EP requirements, it was clear that the Council had taken a firm stance on the security of partially outsourced e-commerce sites.
Here’s why that firm stance is important: If a merchant’s e-commerce site redirects customers in any way to a third party for payment processing and the merchant’s site is compromised, the link or iframe could be redirected to a bad guy to collect payment information. It therefore makes sense that these e-commerce merchants should go through a much more rigorous SAQ/scan process.
In late May the Council released a 3.0 SAQ Guidance document. We received it with great interest, looking for further insight into the specifications of SAQ A and SAQ A-EP. Unfortunately, the examples provided by that document appear to be in conflict with the requirements set forth in the SAQs themselves.
A change in position?
In a previous post (prior to receiving the Guidance document) I pointed out that most e-commerce merchants who previously used SAQ A would now be required to validate their compliance using SAQ A-EP. The only exception would be a merchant who outsources their whole e-commerce website, including shopping pages and payment page, to a third-party, PCI-compliant service provider host. This observation was based on the following eligibility statement for SAQ A-EP:
“Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor”
(Source: SAQ A-EP, p. iii)
In the subsequent Guidance documentation, however, the Council says that a merchant can still use SAQ A if:
- Merchant website provides an inline frame (iframe) to a PCI DSS compliant third-party processor facilitating the payment process.
- Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process. (Source: Understanding SAQs for PCI DSS Version 3, p. 5)
The problem with the above is that if your website “provides an inline frame (iframe)” or your “website contains a URL link redirecting” then you DO control “how consumers or their cardholder data are redirected.” Therefore, the statements in the SAQ A-EP requirements and the examples in the Guidance document appear to be in direct conflict with each other.
This is a meaningful change of position because the Council is saying that SOME types of redirection are OK, but most security experts will tell you that ANY redirection is risky. Forensics auditors have indicated that there are plenty of real-world examples where both simple URL redirects and iframe redirects have been hijacked, sending customers to false payment pages where their credit card data is then stolen.
While we know online merchants have been breached according to the scenario I just described, we do not know how many of these breaches have occurred or cybercriminals’ propensity to use this tactic. The Council’s apparent change of position may reflect a probability-based mindset, recognizing the reality that merchants with other methods of processing, such as POS systems, are more likely to suffer a breach since they require a less sophisticated approach in most cases.
What does all of this mean?
Some may find that the Council’s guidance creates nuances that can be confusing, making it more difficult for e-commerce merchants to discern which SAQ they qualify for. Beginning with the version 3.0 SAQs, e-commerce merchants will qualify for one of three SAQ Types:
- SAQ A,
- SAQ A-EP, or
- SAQ D-Merchant.
Many merchants could have trouble understanding the type of hosted payment solution they have in place and therefore, which SAQ to complete. Here is a helpful synopsis of how ecommerce merchants qualify for the different SAQs, based on the new direction from the Council:
SAQ A:
- Merchant website is entirely hosted and managed by a PCI-compliant, third-party payment processor, OR
- Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, where no elements of the page originate from the merchant website.
SAQ A-EP:
- Merchant website creates a payment form and “direct posts” payment data to PCI-compliant, third-party payment processor, OR
- Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, BUT some elements of the payment page originate from the merchant website. (Elements would be JavaScript, CSS or any functionality that supports how the payment page is created.)
SAQ D-Merchant:
- E-commerce merchant that cannot meet the criteria for SAQ A or SAQ A-EP, OR
- E-commerce merchant that stores credit card data, OR
- Payment pages are delivered from the merchant’s website.
What does VikingCloud recommend?
Because the dramatic differences between the 3.0 SAQ A and SAQ A-EP introduce confusion and do not account for iframe specific security risks, we are recommending that all e-commerce merchants who outsource any aspect of their payment pages validate their compliance using SAQ A-EP.
As a payment security company, we will always consider the most secure solution to be the appropriate choice. While our recommendation takes a more conservative approach than that specified by the Council, ISOs and acquirers have the flexibility to run their PCI programs as they see fit and can decide to be more or less conservative.
Steps for achieving compliance.
Contact the VikingCloud team to help ensure your organization is PCI DSS compliant.
.webp)
