Frequently Asked Question
Why is there a different approach for Direct Post implementations than for iFrame and URL redirect – what are the technical differences and how do they impact the security of e-commerce transactions?
The way that criminals attempt to hijack card data from e-commerce transactions depends on the way that the merchant's website accepts cardholder data, the difficulty of gaining access to the transaction, and how likely it is that the criminal will receive an ongoing supply of cardholder data. PCI DSS aims to reduce the probability that a criminal can steal cardholder data from a merchant's e-commerce transaction. In the last three years, the industry has seen two types of attacks against merchant websites which do not directly process cardholder data but which work in conjunction with a payment service provider. Typically these merchants completed SAQ A as they believed that all their payment processing was outsourced. Because of the nature of the attacks, the payment card brands and PCI SSC have clarified the conditions where a merchant can legitimately consider processing to be outsourced.
To be eligible for PCI DSS v3 SAQ-A, the e-commerce environment must be fully outsourced such that: "The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s)." A merchant website can either redirect the consumer to a third-party payment page, or embed the third-party payment page in an iFrame. In either method, the main attack a criminal has against this is to change the code on the merchant's website so the consumer is re-directed to the criminal's payment page and not the legitimate payment page – this is commonly known as a “man-in-the-middle" (MITM) attack. The disadvantage for the criminal is that this attack is usually detected reasonably quickly and minimal cardholder data is put at risk. Additionally some payment service providers are developing solutions that help to detect when a MITM attack has occurred and to notify the merchant accordingly.
Where merchants or QSAs are unsure whether the correct SAQ to be completed is SAQ A or SAQ A-EP, they are advised to firstly determine whether "The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s)". If any element of a payment page originates from the merchant’s website, the implementation is not eligible for SAQ A. If any element of a payment page originates from a non-compliant service provider, the implementation is not eligible for either SAQ A or SAQ A-EP. If it is unclear whether this condition has been met, merchants or QSAs are advised to contact the acquirer or payment brand.