Finally, A Standard With Teeth

Remember the early days of e-commerce?

There was a flurry of companies born to handle the transfer of money over the Internet. First Virtual used an out-of-band system that involved phone calls to an automated processing system. Cybercash was going to be the new money of the Internet but evolved into a payment gateway for credit card transactions. The SET protocol was in its final version when SSL was introduced in the Netscape browser and e-commerce took off.

I had an opportunity to learn the ins and outs of payment processing as head of a venture to sell gift certificates online, called i-gift. Back then (1998-99) Visa and Mastercard handled the increased risk of fraud by lumping e-commerce merchants into the same group as catalog sales over the phone – so-called "card not present" transactions. They took an extra couple of percentage points from every transaction to pay for the higher losses due to people using stolen credit cards.

At i-gift, we had one crook who would regularly go online and purchase $800 worth of gift certificates to the Somerset Collection in Troy, Mich. (one of the highest sales-per-square-foot malls in the U.S.). It was always $800, oddly enough, and we were expected to ship them via UPS to an address just south of 8 Mile Road in Detroit. This guy would then go and redeem them at the mall for computer equipment.

Our volumes were low enough that we caught on to this quickly and just did not accept those orders. I remember even back then that we were smart enough not to store credit card information. The merchant only needs to store a transaction verification number.

Yet, the norm for small e-commerce solutions was to capture the credit card information, encrypt it, and send it via email to the merchant who would then manually enter the transaction via a point-of-sale terminal. This led to all sorts of problems as eventually cyber crooks figured this out and started to target the files where credit card information was stored. Bigger and bigger losses of information started to occur.

Increased public disclosure of losses (remember Egghead Software or CDNow?) led to the credit card associations beginning to worry about their brands. They instituted security standards for merchants that were, frankly, just polite suggestions. Finally, in 2004, Mastercard and Visa got together and published the Payment Card Industry (PCI) security standard.

Yes, another ingredient in the alphabet soup of regulations that demand compliance (HIPAA, SOX, GLBA, CA 1386). Yet PCI is different in two very important ways: origin and enforcement.

Unlike the others, PCI is not a regulation at all. No government body was involved in setting it up. It very simply is a set of requirements that every single merchant must abide by or risk losing the ability to accept credit cards. The threat of losing a significant source of income gives PCI more teeth than HIPAA, Graham-Leach-Bliley, or even Sarbanes-Oxley. After all, there are no HIPAA police. GLB and SOX are used as guidance for financial regulators and the SEC – but the requirements are very loose and hard to interpret, while enforcement has yet to be demonstrated.

There are only two things to remember about PCI: Thou shalt not store magnetic stripe information (credit card number, CCV, etc.) and thou shalt regularily scan your Website for security problems. The PCI standards have a lot more room for becoming stricter, but for now they go a long way towards protecting a merchant from loss. If you handle credit cards in any way, you should seek to become PCI-compliant right away.

If that is too much of a burden, you should outsource your transaction processing. Let someone who is compliant handle your transactions. PCI compliance is one area that you can focus on, knowing that you will get immediate returns in terms of reduced exposure and less risk.

— Richard Stiennon is founder of IT-Harvest Inc. Special to Dark Reading