There’s a great deal of nervousness amongst e-commerce merchants concerning the perennially thorny topic of compliance with the Payment Card Industry Data Security Standard (PCI DSS).
There has always been ambiguity surrounding what falls within scope, and this was highlighted last month when news of the TalkTalk hack broke. As the latter pointed out, companies are not legally obliged to encrypt sensitive customer data, including bank details, unless they are actually processing payment card information. However, merchants and payment service providers (PSPs) have been asking more questions since PCI Version 3.1 came into effect in April this year, which followed Version 3.0 in January 2015.
Prior to Version 3.0, merchants handling fewer than 6 million transactions per year (i.e. Levels 2-4 under PCI DSS) could use a hosted payment page from a PCI-compliant PSP to de-scope their own web infrastructure. All they had to do was complete a self-assessment questionnaire (SAQ) and Attestation of Compliance.
Under Version 3.0 however, the responsibility of compliance for all 12 key areas falls on the merchant, irrespective of whether they’re working with a PSP. Yet we’ve seen too many instances where merchants continue to assume that their infrastructure is not in scope because theym outsource aspects of their payments page. This assumption is incorrect.
The bottom line is that if merchants are being told by their PSP that they’re out of scope because they use a hosted payment page – whether via a URL redirect or inline frame (iframe) – they are being sold false information and are exposing themselves to the risk of substantial fines and reputational damage.
All change with Version 3.0
There are multiple types of SAQ under PCI DSS [see Table 1] – from A through D – to meet various business scenarios (download the Visa e-commerce payments guide for more on this). Prior to the introduction of Version 3.0, merchants processing under 6 million transactions a year and using a hosted payment page were required to complete SAQ-A, which at 14 questions and an Attestation of Compliance was relatively simple.
But while SAQ-A still exists for Version 3.0 and has seen only minor revisions, merchants who use hosted payment pages are now subject to the SAQ A-EP (Electronic Processing), which has 139 questions and calls for a quarterly ASV Scan and annual penetration test.
The SAQ A-EP has been introduced because the PCI Standards Security Council (SSC) now recognises that a merchant’s web infrastructure could impact the security of payment transactions. For example, an attacker gains access to the underlying host operating system running a merchant’s website, edits the file controlling the redirect and points it to a fake payment page where an unsuspecting consumer’s card details are harvested.