A dozen years ago, I was working for a software development company that created mainframe-based software used to process Visa and MasterCard transactions. System changes were difficult, painful, and costly. Change also was a constant.
Just as any other software developer, we were always working on the next “big release” as well as “fixes” that would be bundled into quarterly releases. But what really made our product development team nervous was another set of requirements: the quarterly announcements that came from Visa and MasterCard, announcing business “enhancements” that needed to be reflected in systems processing their transactions.
I’ll never forget when it was announced that one of the big-box bargain stores was being welcomed into the fold, with a special deal on the amount of credit card fees it would be charged for each transaction. Newspapers rejoiced; this was good for the economy and proof of the power of such megastores, the stories said.
At work, however, we weren’t rejoicing. The megastore was being treated as its own class of customer, which meant we had to add a value to a significant reference table. We had to find every piece of “IF-THEN” code referencing those values and add another set of processing instructions. We had to update user interfaces, reports, user documentation, system documentation, and all our testing routines. That one little code added to a single reference table was going to result in thousands of hours of work for us.
But we had no choice. We had to do it. We were subject to Visa and MasterCard compliance; if they said we had to change our software, we had to.
Besides, we also were subject to contractual compliance. Our customers were counting on us to make the changes, so they could update their systems and start accepting charges from the big-boxes. If they weren’t up and running on time, they’d be incurring the wrath of millions of consumers who wanted to pull out their plastic and proudly declare, “Charge it!”
And now, many years later, credit card software compliance is in the news again. It seems many companies are crying that it’s difficult to comply with the Payment Card Industry Data Security Standard (PCI-DSS) cosponsored by Visa, MasterCard, American Express, Diner’s Club, and Discover, and required as of Dec. 31, 2007.
I hear their pain. I really do. But even more than that, I hear those millions of consumers, nervously handing over their credit cards and muttering, “Do I dare?” And they’re right to be concerned. After all, somewhere between 45 and 100 million user accounts were acquired by data thieves during the infamous TJX security breach. TJX had an outdated wireless security encryption system, they failed to install firewalls and data encryption on computers using the wireless network, and they didn’t properly install another layer of security software. As a result, thieves sitting outside a store in a van were able to access data streaming between hand-held, price-checking devices, cash registers, and the store’s computers.
Such breaches should be blocked in environments that comply with PCI-DSS requirements. Compliance is hard— there’s no mistake about that. But it’s the right thing to do to protect credit card issuers, processors, and consumers alike. There’s a very good reason that, in this case, compliance isn’t optional.
Here’s a summary of PCI requirements for you to keep in mind: