There are millions of websites transmitting or processing payment card details online! It’s one of the easiest, most ubiquitous ways for your customers to pay for your product or service from the comfort of their own home. Most businesses that insist on having people call to set something up lose out on potential revenue daily – you can probably remember a time when you were checking something out online and decided something intriguing wasn’t worth calling someone about. Then you probably forgot about it.
Sadly, while buying things online is easy for customers, selling things online can be a huge hassle for businesses. It’s such a hassle, in fact, that several people have arbitrarily declared it’s much easier than it actually is! I want to call out some of the most pervasive myths and set the record straight so businesses don’t end up getting fined for noncompliance. I hate to be the bearer of bad news, but what else can be done with so much misinformation out there?
MYTH #1: You just need HTTPS
If you’ve heard that you just need an SSL certificate and run your website off of HTTPS, then you’ve heard from someone sharing their terribly convenient delusion. At one point this may have been true, but if you want to legitimately accept payments online then installing an SSL certificate is one tiny piece of the puzzle.
This myth is easily the most pervasive one out there – until I actually dug into what constitutes PCI compliance for websites, I believed it myself! Because of that, I know how easy it is to respond to discovering the actual PCI DSS requirements with something like, “That can’t be right.”
But it’s totally right. Don’t take my word for it – if you want to dig into the requirements yourself, here are a few resources for you to look over:
So yes, getting your website to the point where it can process card transactions without risking liability and fines can be a large undertaking. But if you’re just a mom-and-pop web store processing a few dozen dollars a month, you’re okay, right?
MYTH #2: You only need to worry about PCI compliance once you’re big
“PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of their size or transaction volume.” –PCI Security Standards Council
Once you hit a certain level of monthly transactions, you’re required to submit a PCI DSS self-assessment questionnaire (SAQ) that asserts that your business processes credit cards correctly. At that point you’re officially on the radar of the Payment Card Industry, and have to start proving you know the rules and are following them.
But compliance isn’t just required once you hit that level. It’s always required for anyone dealing with credit cards online! If a single credit card touches your website, and the website is not PCI compliant, then you risk losing the privilege of not being on the PCI radar.
Not being on the PCI radar and being in good standing with all major CC companies is one of those privileges you take for granted until the day you lose it. If your company is involved with a data breach or hack that touches CC data in any way, you jump all the way from level 4, aka “we trust you to maintain compliance without us hounding you”, to the depths of hell that is being a level 1 merchant.
Level 1 merchants don’t fill out any questionnaires – they have to hire a qualified PCI compliance auditor to come and perform a full audit of how their company processes and/or transmits credit card data to make sure they are in compliance. If you thought the SAQ was long, imagine having an outside consultant getting paid by the hour to come into your business and figure out the answer to each question. These specialized consultants are used to being hired by companies that process more than 6 million CC transactions per year, and their services are required for level 1 merchants to process CC transactions… so you can imagine their rates, but it may be better for your overall health to avoid doing so.
All that you need to be stuck as a level 1 merchant forever is a single data breach or hack that touches credit card data. Once that is on your record, you don’t get to go back down to the good ol’ days of filling out an SAQ and running a scan.
The SAQ + vulnerability scan is the bare minimum effort needed to sell things online, and trying to avoid it only heightens the risk that you will end up needing to do it, pay fines, and maybe pay for an auditor every year too.
MYTH #3: You can achieve PCI compliance on any web host
Do you use FTP to connect to your site? If so, you’re out of compliance. Do you have two-factor authentication in place for connecting to your website’s admin panel remotely? If not, you’re out of compliance. I could go on but these are the two big dealbreakers – Common situations amongst shared hosts that are difficult (if not impossible) to change. This is because most shared hosting providers are antiquated relics of a time when requirements to host a website were much simpler. Nowadays they work for tiny blogs and other personal sites, but I don’t know of any website that has actually achieved PCI DSS 3.1 compliance on a shared host. This is because many of the compliance measures require configuring the webserver itself, which is flat-out impossible on a shared host.
Here’s my own experience with this: After the 3.1 PCI DSS updates, a website running off a shared host that transmits donations to an external payment processor went from years without any issues passing compliance scans to several auto-fail issues. Many of these failures were triggered due to server software updates needing to be installed to close publicly-disclosed vulnerabilities such as this year’s BIND vulnerability. The shared host just never ran the updates and never closed these holes as long as we were there. Beyond that, we couldn’t disable FTP and couldn’t require two-factor authentication for our users… and when we submitted a ticket for help, our support contact just told us to answer “yes” to the entire SAQ without worrying about the actual answers to the questions. In other words, we could no longer process payments online because everything the shared host “took care of” was woefully out of compliance.
Instead of ignoring PCI compliance and letting the organization be incredibly liable for any CC fraud, I transferred the site to a new webserver on Amazon Web Services that WAS PCI compliant. Bonus – the exact same website files went from loading in 1.6s to .7s on average, AND the hosting costs are less! This is what happens when you stop trusting dinosaurs to host your website!
So Now What?
In 2015, PCI DSS got a whole lot more strict and with good reason. With that said, I really do apologize for shattering the dreams of anyone who read this thinking that PCI DSS = running your site on HTTPS! Just be glad you found out this way instead of having to pay fines and/or hire an auditor every year 🙂
Can you think of any other common myths about PCI Compliance? I’d love to hear them in the comments!