If you handle credit card payment data in your company, you're probably familiar with the Payment Card Industry Council. But they're no longer the only game in town. Maybe it's time to look at the broad issues.

If you handle credit card payments in your company, you know that PCI compliance has been the gold standard for the last decade. And if you've been paying any attention lately, you know that Apple Pay was announced in October 2014 and is getting a lot of press as being the future of electronic payments.

But what are the differences and similarities between these two methods? Are they complementary? Mutually exclusive? Let's take a quick look behind both of their curtains.

Payment Card Industry (PCI) Council

The Payment Card Industry Council, a loose organization of banks and retailers, sets "standards" for the processing of electronic payments.

I say "standards," but they're really a series of guidelines and best practices, rather than a specific software or hardware solution. The more of these standards that you follow, the more PCI-compliant you are, and that's considered a good thing. The council is forever releasing new versions of its guidelines (as they should), and in fact last month they released two new best practice documents.

The first is Terminal Software Security Best Practices, which is designed to address software that's on the Point of Interaction (POI) hardware used during the PCI transaction. These guidelines are primarily oriented toward the makers of these devices, but it does give the people who buy hardware something to think about.

The second is Updated PCI PIN Security Requirements. PINs remain a major target for criminals, and much of the new guidelines is related to the hardware that captures the PIN—for example, using a secure PIN block, using non-random cryptographic keys that aren't unique to the device or that don't change, not using cryptographic devices at all on a PIN, and not maintaining logs or audits of PIN activity. It's all very exciting.

PCI is oriented around the fact that, when you take a credit card transaction, you send a variety of pieces of information (credit card number, expiration date, security code, etc.) from the hardware reader through the online network to the bank and possibly some intermediate points as well (common for small retailers). Naturally, the retailers have your card information. They get it when you scan your card through the reader. But as it goes through each check point in the journey, someone else may be able to grab it as well. For example, small retailers often go through some sort of gateway to reach the bank. Can you spell "gateway may copy the data too"?

And that's where the fun begins. According to the PCI, 81% of business in the U.S. and Europe store card numbers, 73% store card expiration dates, and 71% store the verification codes. That makes a mighty tempting target for hackers. And as the number of card data thefts have gone up this year, we can see that it's a target they find impossible to ignore.

In general, the actual transmission of the data isn't the weak point; it's when the encrypted data is stored for various uses that there can be trouble. Banks need it, of course, but retailers and others (such as gatekeeper organizations), keep the information for sales analysis purposes.

Apple Pay

First, let's define some terms, starting with the Near Field Communication (NFC) chip. This chip allows two devices to communicate with each other when placed near each other. Obviously, both must contain an NFC chip.

Second, there is the Secure Element (SE) chip. This is a hardware chip and isn't connected in any way to the software of the smart phone, so even if someone hacks into the phone, they can't get to this. (There are also protections against physically breaking into the phone and stealing the chip.) This chip is where your credit card information is stored, and it generates a 16-digit random token that represents the card information.

When you put your phone up to the card reader, the NFC chip allows the two to talk to each other. After exchanging a few pleasantries, they get down to business. The phone prompts you to scan your fingerprint (it's the biometric equivalent of a PIN), which then activates the SE chip to create the "token." This random 16-digit field is what is sent to the bank (rather than all your card data). Consequently, the retailer does not see your card information and has no way to store it.

At the bank, the token will be taken apart and the card data in the bank's database accessed. The bank will then do what it does to decide whether to approve the transaction and, if it does approve, will return the authorization information. What it returns, however, is not a blanket authorization that could be used again in the future but a one-time code that isn't valid for any future use of that card.

So Goodbye PCI?

It's tempting to say that, isn't it? But nothing is ever that simple. Apple Pay is something you do in person. You have a fingerprint recorded as your PIN. PCI is available for online transactions. At this point, one is not going to replace the other.

But changes are coming. What PCI offers is suggestions on things that you should and should not be doing. Tokenization offers hardware that puts secure data a little further out of reach of the people who would like to get it but have no business doing so. And certainly Apple Pay's take on this will change where things go from here. But PCI is a standard, and standards can adjust. Perhaps Apple Pay and full acceptance of tokenization will lead to a new, simpler, more-secure set of standards.