If you take credit or debit card payments online, you probably know you need to be ‘PCI compliant’. What you may not know is that from January 2015 the PCI compliance rules are about to change. And in a big way.
Depending on how exactly you take payments, what you have to do to be ‘PCI compliant’ could be getting a lot more complicated.
There’s always been confusion around the PCI rules. Different merchants and people advising those merchants have interpreted the rules differently. And new technologies have arrived on the scene with new implications for security. To clear up some of the confusion and to address security concerns around these new technologies, from January 2015 the PCI Security Council is introducing a new revision (version 3.0) of their Data Security Standards (PCI DSS).
The big thing to know about the version 3.0 PCI DSS standards is that what you need to do to be PCI compliant is going to depend heavily on how exactly you’re taking payments on your site. The rules around this are going to be clearer than before. And they’re going to surprise a lot of people.
The standards identify three different categories for e-commerce businesses:
1) Hosted store/payment page/payment iFrame: you qualify for SAQ A
If (i) you’re using a compliant SaaS ecommerce platform (such as Shopify or BigCommerce), (ii) you redirect your customers to a secure payment page hosted by your payment processor, or (iii) you take payments via a secure iFrame provided by your payment processor, then you qualify for the simplest level of security measures. Your payment provider will ask you to complete a self-assessment questionnaire called ‘SAQ A’ to confirm you’re following some quite straightforward security practices.
If your customers enter their card details into a form on your site that uses technology such as Stripe.js to send the card details straight to your payment processor without ever passing through your server, then you’ll need to complete a much stricter security self-assessment questionnaire called ‘SAQ A-EP’. This is much more demanding than SAQ A.
3) Anything else: you qualify for SAQ D
In any other case you’ll need to comply with the strictest security requirements and complete ‘SAQ D’.
The big issue here is around category 2.
A lot of small merchants have started using technology like the Stripe payment company’s Stripe.js assuming that this would keep their PCI obligations quite minimal. They’re the ones about to have a nasty surprise. With over 100 technical controls to have in place, complying with SAQ A-EP is far from minimal. In many cases it just won’t be feasible for small merchants to truly comply with it all.
These small merchants are going to have a couple of options: either change how they take payments (so that they qualify for the much simpler SAQ A) or be less than truthful somewhere in their PCI self-assessment documentation.