It’s Time To Change Credit Card Processing

In the past week I’ve gotten two notices that my credit card data might have been obtained in a retail site hack. That’s two too many and it got me thinking about how we process credit cards. The current method many websites use doesn’t make any sense. I cut my teeth in this industry in the late 90s / early 2000’s as a web developer and software engineer, and it astounded me how we handled data even back then. I haven’t really implemented any credit card processing in years so maybe it’s changed and the sites I’m reading about haven’t kept up, but somehow I get the impression that the whole system is messed up.

In the early days of handling passwords, developers quickly learned that storing them in plain text just didn’t make sense. To authenticate users, we didn’t actually need your password. We just needed to store an encrypted version of it, then encrypt whatever you typed into the box and see if they matched. We used one-way encryption to store them so if somebody hacked our password list it wouldn’t do them any good without a quantum computer – which the NSA hasn’t figured out how to create yet.

When it comes to credit card handling though, we’re not as smart.

Too many sites store the full credit card number and customer information – even if they don’t really need to. Sure, many customers want this feature so they don’t have to enter their credit card every time (I, on the other hand have simply memorized mine.) It’s also useful for recurring charges – I hate to think about how many domains I’d lose if not for Godaddy automatically renewing them with my credit card every year.

It’s clear we need the ability to set up recurring charges for customers, and it’s clear we need the ability to issue a refund without asking the customer to enter their card again – but none of these things inherently require storing the credit card information in plain text.

Sure many sites encrypt the credit card info, but since they know they’ll need that info again they use 2-way encryption. The problem with 2-way encryption is that it can be broken; sometimes rather easily. Another problem with 2-way encryption is that the decryption key (and code to decrypt them) is also stored on the same server. If somebody hacks into our credit card database it’s pretty safe to assume they have access to our code also, thus the encryption is pretty useless.

So how do we fix credit card processing?

I was recently playing with the Google Glass API (Yes, I’m a glasstard) and it forced me to use Oauth2.0. That’s when it hit me, we currently have a more secure process in place for logging into a site with Google or Facebook than we do for charging people’s credit cards. Does that seem absurd to anybody else? It’s (sometimes) harder to hack into my friends list than it is to steal my identity.

We need to completely change how we process credit cards, and OAuth2.0 gives us a good model to build upon. Here’s how the new system would work:

For One Time Charges:
1.) The user enters their info.
2.) The site encrypts the info and sends it over to the credit card company for verification.
3.) The credit card company passes back a status and a transaction ID.
4.) The merchant stores only the transaction ID.

Now, the credit card information is stored in only one place: the servers of the company that issued the card. If the merchant needs to issue a refund, they can do so with the transaction ID.

So what about recurring charges?
Steps 1-3 are the same.
4.) In addition to a transaction ID, the credit card site sends back a re-charge token. This token will ONLY work with the merchant ID of the site, and ONLY from the same domain name that initially requested it. This token will also expire in 30 days. The site will need to keep track of when tokens expire and ask to refresh them periodically. When that happens they’ll be given a new token.
5.) In this instance, the merchant will store your customer info, your transaction IDs, your re-charge token, and the date they received it.

Now, if a site is hacked they simply need to change their merchant ID and refresh their tokens. The old tokens are instantly useless and the hackers have no information they can use against you. There’s a small window where they could put code on the hacked site to charge the cards, but they wouldn’t receive any money – it would go into the hacked site’s account where it could be easily refunded.

In a nutshell, that’s how OAuth2.0 works (You know, that system that lets you login to post a comment with your Google, Facebook, Twitter, or Yahoo ID) There’s a few credit card processing sites out there that actually use similar methods, but I’m not just talking about online. I’m talking about in-store too. It’s often the case that manufacturers assume nobody will hack into their point of sale systems, so they often take security shortcuts.

Why we don’t use a similar system for more important things like credit cards and bank charges is beyond me. (If I get more time I’ll tackle the fact that many banks still use physical paper checks and the US mail to transfer money between accounts.)

Side note: Looking at the CES coverage this year, all I’m seeing is “bigger” “thinner” “smaller” “faster” products, but nothing groundbreaking. If you’re looking for an industry to disrupt where you can actually make a difference, here’s your idea. Let’s get innovating.

Ryan Jones is an SEO from Detroit. By day he works as a manager of SEO & Analytics at SapientNitro where his team performs SEO for Fortune500 clients. By night he's either playing hockey or attempting to take over the world with his own websites - which he would have already succeeded in doing had it not been for those meddling kids and their dog. The views expressed here have not been paid for and belong only to Ryan, not any of his employers or clients. Follow Ryan on Twitter at: @RyanJones, add him on Google+ or visit his personal website: www.RyanMJones.com

About Ryan Jones

Ryan Jones is an SEO from Michigan. Ryan works as an SEO manager at SapientNItro. Ryan also runs several websites of his own. [More About Ryan..]