Accepting Payments Is Getting Harder
PCI compliance is not really something often talked about in startup circles, but PCI is changing, and it’s getting a lot harder to comply.
In January 2015, PCI DSS v3 was put into action, this is quite a drastic change and increase in requirements from v2. While there have been some writings about this, it hasn’t really made a big buzz in startup circles. But this is a pretty big deal, not least because it shows a trend of what we can expect for the future. I have talked to Vantiv, Chargify, Recurly and Stripe and compare their PCI requirements in this post.
Now let me be clear, if you have less than 20,000 credit card (CC) transactions a year, you’re not even on the CC processors radar. But if you’re in the 20,000 to 1,000,000 transactions range (these are the limits set by VISA) then you classify for a PCI Level 3 compliance requirement (lower numbers have higher requirements, so Level 1 is the worst). This article is for us Level 3s.
If you’re storing CC information in your own system, stop doing that and use a third party service, the PCI compliance requirements are vastly different for those storing the data vs those that simply use a third party service. If you are using a third party service for storing CC information then you have to be compliant with PCI DSS (Data Security Standards). Relative to the full PCI auditing process, the DSS requirements when using a third party service are fairly easy to comply with, and for Level 3 you don’t even have to be audited, just fill out a Self Assessment Questionnaire (SAQ).
So those are the basics, but what has changed? Up until January 2015, if you were a Level 3 using a third party service you needed to fill out and comply with SAQ A. SAQ A consists basically of 13 questions, the sum of which boils down to “Is the data stored securely?”, and if your third party service is doing its job the answer is simply Yes.
Now the new standard introduces SAQ A-EP, this extends the assessment questionnaire and compliance requirements to 139 questions. Many of these new requirements will directly affect the way you can run your business and the level of overhead you will incur. Most of the questions are basic sensible things that you should be doing, like having a correctly configured firewall, don’t have any intermediate storage of CC information, to explicitly requiring TLS for all communication. Some of the requirements I believe are downright harmful to security, like “Are user passwords/passphrases changed at least once every 90 days?”
The worst offenders however are the requirements that some businesses simply cannot comply with unless they have some serious cash laying around. Examples of this are
Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).
and
Is external penetration testing performed per the defined methodology, at least annually, and after any significant infrastructure or application changes to the environment (such as an operating system upgrade, a sub-network added to the environment, or an added web server)?
Note that the requirement for penetration testing can be satisfied by an internal resource, but they have to be qualified and need “organizational independence”.
These things are not easy to comply with and will significantly harm a wide range of online merchants.
“But surely, these can’t be requirements, I know a ton of companies that take online payments that don’t comply with this.” I hear you say, and you’re right. Disregarding the companies that are simply not complying and just aren’t caught, there are still “loopholes” to avoid having to comply with SAQ A-EP and still let you get away with filling out SAQ A. According to the SAQ Guidance document, the requirement for SAQ A vs SAQ A-EP goes like this.
To be eligible for SAQ A [one of the following need to be met]: * Merchant has no access to their website, and the website is entirely hosted and managed by a compliant third-party payment processor * 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.
I have talked to Litle/Vantiv, Stripe, Recurly and Chargify about this issue and what they offer to help mitigate the new SAQ A-EP requirements.
Both Litle and Recurly flat out say that you need SAQ A-EP. Recurly does offer a hosted payment page but for some reason their support and their documentation still says that you need SAQ A-EP compliance to use their product. I have heard rumours from other sources that the PCI council plan to remove the iFrame loophole in the future, maybe Recurly knows something we don’t? In any case, if you don’t want to break the rules you can’t use Recurly unless you are compliant with SAQ A-EP.
Chargify has an excellent article outlining all the PCI requirement business and what you need to know to deal with Chargify. Unfortunately the article is from 2011 so it doesn’t take into account the new standards and their support seemed unaware of any new standards. By chance though, Chargify has a hosted page service so you will still be able to file under SAQ A with them if you use that.
The leader of the pack when it comes to innovation and keeping up with the issues is Stripe. Not only was their support the most knowledgeable, directing me to the relevant documentation from PCI website but also talking about how they are changing Stripe.js to now serve up the data in an iFrame so you can keep using their product more or less like before but without heightened requirements. Stripe also built the questionnaire into their product and will show you on your dashboard when you need to fill it out and be compliant, they are actively trying to help you with compliance as well as paperwork. This is in contrast to Recurly who said “We do not assist with these forms, we suggest that you speak with a security assessor.”
At the end of the day, no one will want to implement the full extent of SAQ A-EP, at least not in a low-margin or startup environment. I believe there will always be some loophole to avoid implementing the full extent of it, perhaps iFrames will be removed and we will have to start redirecting users to our third party services for signup/payment.
I haven’t heard of anyone getting shut down because they weren’t compliant, but it’s important to remember that it usually isn’t a third party service that will come knocking on your door. It is the credit card companies that are ultimately in charge of trying to enforce this. If you get to enough volume where VISA sees you and starts paying attention to you, they will come knocking on your door or tell your payment gateway to knock, and by the time that happens, you may very well be set up to deal with it. It’s not law and there are no fines for not complying, to my knowledge the only risk is that they stop processing your payments. Obviously it’s not fun living in that fear, which is why I believe that services like Stripe, that help you out with these issues, will thrive.