Proper credit card processing on the cheap
At Bytemark a couple of thousand people per month need to pay us money. We don’t offer barter or cash as payment options, which stops folk turning up to the office with livestock or pieces of eight (except sometimes on Talk Like a Pirate Day). The reason is that we’re only a staff of seven and we would probably spend all of our time meeting customers, offering them coffee, then assaying their bullion or sizing up the hindquarters of their cattle and taking them out to pasture in the car park. We did once receive a grubby tenner in the post in payment for a domain, but that’s as close as we came to actual physical exchange. The advantage of exchange is that, well, you meet your customer, you see what they’re offering for your services and you can decide on the spot whether you want to take it or not. If their coins are too clipped, or their sheep lame, well, you send ’em away, no sale.
Of course, for economic sanity, we take card. But in these days of the credit crunch, we should probably know what that means. And I think it’s amazing it still works at all. The card system was invented by a New Yorker who forgot his wallet once at a restaurant and promised to pay them later. Initially Frank McNamara issued Diners Club cards to 200 salesmen to spend in only 14 restaurants; the salesmen flash them at waiters, who would write down the card number, and the amount of the bill, then claim back the total balance from the Diners Club corporation at the end of the month, who would in turn bill their cardholders. Security must have been nice and easy – the embossed pieces of plastic were hard to come by, and the types of people who carried them were easy to spot – white, male, dressed-to-impress sales and executive types.
Despite trumpeted advances in credit card security over the last 10 years, this rather gentlemanly payment model is the one we, and our customers, rely on, to pay us for services, and the one which we’re going to have to keep relying on for the foreseeable future. We ask the customer for their secret numbers when they sign up. We ask the bank, every month, whether we may please have £15 or more to pay for that customer’s service, quoting their secret number back to the bank. Assuming the secret number is correct, the bank gives us our money and the customer’s account is paid.
The trouble is – thieves. They hand over other people’s card numbers to pay for our services, and the bank will give us their money without question. Bastards! We’re not a fancy New York restaurant, and the customer isn’t looking us in the eye and saying “a delightful meal, sir! Please bill my Diner’s Club club account!” So we don’t have the visual clues to size up a rogue. At Bytemark, we know our customer profile well and will check an order far more thoroughly if the customer claims to be a grandmother in Arkansas than a network consultant from Leeds. It’s unpalatable in principle, but the shopkeeper’s best defence has always been to know his likely customers, and be wary of “strangers”.
But fraudulent purchases isn’t our biggest concern with taking cards. Despite chip and PIN, CVVs and other security changes in the card system, it’s us merchants who need “continuous authority” that is the card industry’s biggest risk! That’s because we need to be able to store and re-use our customers’ card details so that they can pay for small items without handing over their card number for every few pounds they want to spend. The thieves we need to worry about are the ones who are targeting our customers’ account numbers, which our business model obliges us to store.
If those numbers got out en masse, the banks would easily spot that it was our fault because they would be able to correlate the charges made by us with fraud reports reported by our customers. They could potentially take away our ability to take payments by card in this scenario. However, a quiet penalty charge would be more in keeping with the card company business model, as overall confidence in the card system is more important to them than real security. When mine and my partners’ business debit cards have been included in a compromised haul of card numbers, we spot the fraudulent transactions and report them, getting our money back quickly. However, the banks never tell us which merchant was likely to have led to the compromise. They might have identified and fined them, but they don’t want us to worry to whom we should or shouldn’t trust our card numbers.
As an aside, it would be better if the banks would protect their customers with fundamentally more secure cards. They could allow customers to make up new account numbers which worked for particular merchants, or for only a certain sum of money, to contain the damage from any data security problems. Instead, they have gone for the “stick” solution: fines and sanctions of merchants who store credit card information improperly. Now that credit and debit cards are fundamental to many business’ revenue streams, they don’t need to spend on further security themselves, instead of forcing the risk and cost out to the merchants.
Merchants are told how to store and process these lists of secret numbers- it’s called the Data Security Standard. It was initially a set of recommendations, but compliance is now a condition of getting a merchant number (at least from Barclays). If you store cards as we do, and haven’t planned how you do so, it might entail a complete overhaul of your company’s IT infrastructure and policies (which, given the financial risk to their customers of a compromised card database, is the only sensible option). It is arguable that full compliance is impossible in all but the most dogmatic bureaucracies, and the actual check for most merchants is nothing more than a port scan which costs you £100.
Our secret to complying with the DSS is segmentation! And this has just been recognised and recommended as a valid technique for compliance in the hot-off-the-press new version of the document (release only a few days ago). Now I’m going to talk about our card processing network and I really think it’s one of the best ideas out there – while I’m honest about its shortcomings and current (technical) non-compliance I should point out that it is secure in all the important areas and far better than similar small businesses. We don’t store cards in a Microsoft Access database on a machine on the boss’ desk. We don’t store them written down in a filing cabinet. (both of these are examples from real companies – probably not the worst ones out there)
We have a whole isolated network dedicated to processing credit cards. It has one computer on it. It has a dedicated firewall box, the computer’s data is encrypted with keys held only by the company directors (so we need to be present to boot the thing up), kept physically in a locked cabinet, in a locked room, guarded by dogs. If we had the room to dig a moat, it would be full of sharks with lasers (I wasn’t joking about the dogs). All for one server, and a few kilobytes of precious data!
The software I’ve written is a “roach motel” credit card database. It allows us three operations: 1) store a new credit card, 2) update or delete an existing credit card, 3) charge one of the cards. The one thing you can’t ever do is read the card details back again. Not even the staff. The system reads them only to transmit them to our payment services provider (then it’s their problem what to do with it), and that leaves over SSL.
Within a few weeks, when customers call up on the phone, we will have finished the last couple of parts. One is a wireless terminal for entry of card data over the phone (an old Nokia N770 tablet device). That way when customers call, we don’t even trust the web browsers on our desktops to enter credit card data for an instant – we find the terminal in the office and enter the secret numbers onto it, which communicates securely back to the card processor. And when customers enter credit card data themselves in order or on our control panel, they will communicate directly with the payment processing machine, just their computer talking to our server with nothing in the middle.
So from a compliance point of view, our hands are clean, and the part of our network which processes the secret numbers (PANs, Primary Account Numbers, as the standard calls them) as small as it possibly can be. This is all thoroughly economically justified paranoia (and fun too) – as we grow and process more card transactions, the audit requirements for compliance with the Data Security Standard become even more onerous and expensive. If we were regularly entering card details through our normal web browsers, for instance, the auditors (when they doubtless arrive) might say, what virus checkers are you running on these? And we might say, we’re not because these are Linux machines and we don’t know of any viruses that would affect them – look, here’s a company selling virus scanning software, why aren’t you buying it. And they would say, well, we had better check all your machines for non-existent viruses just to make sure, and here is a bill for fifty thousand quid by the way. With a small network, we can tell the auditors to keep their noses out of the rest of our network, and we can be surer that our card storage is really safe.
The only thing this leaves is – the software! I’ve written it myself. It’s in production already and has been for nearly a year. It is quite paranoid about its input and is guarded by the excellent pound URL filter, as well as an upstream firewall. The only trouble is, it’s custom software, and we’re the only people using it. The solution will definitely be for me to open it up to public scrutiny, to make it more popular for other companies to use and build confidence. However, I’ll also be investigating the possibility of a paid audit procedure, with a view to it becoming suitable for a “tier 1” payment processor, i.e. the kind where the banks want to send in the men in black to check your company out.
For the moment if anyone else is interested in helping with the software as-is or has implemented something similar/better for their own company, I’d love to talk to you and show off what we’ve done so far. It’s hard to find anything on the internet about this sort of thing in practice because I assume people are embarrassed about their homebrew card processing systems or worried about non-compliance. I will take the leap and open up our software, but I am going to spend a few weeks giving it another coat of paint and some better tests first.
