Update Aug 12, 2011:
The PCI SSC has released an Information Supplement on Tokenization.
Why Reduce PCI Scope?
The primary aim of PCI-DSS is to protect cardholder data. One of the things that I joke about is that the most secure application is the one that is never built. Extending this concept to data, the best way to protect data is not to have (store) it at all. Then you do not have to be responsible for the data or bend over backwards to protect it. When I was in the PCI-QSA training, the instructor kept repeating the importance of determining scope and also reducing scope. The idea is that if you have less to protect, you will (hopefully) do it better and there will be less to look at when validating compliance.
Tokenization – Replacing CCN with Unique Tokens
One of the most important requirements of PCI-DSS is that whenever credit card numbers are stored or transmitted, they have to be encrypted. Encrypting them for storage or transmission and decrypting them for transactions can increase the overhead significantly depending on the encryption algorithm that is chosen. Then there is the management of the encrypting keys that need to be kept secure.
To avoid all these issues, we have to find a way to do away with storing or transmitting credit card numbers. The solution is tokenization; replacing credit card number with another unique number. When the first transaction is performed, the credit card number will be sent to the payment gateway. The payment gateway will then generate a unique token and map it to the credit card number. Once this is done, the merchant does not need to present the credit card number again and can use the unique token instead. The gateway will store the credit card number securely and transmit it securely to the payment processor.
There will be a unique token for each credit card presented by a customer and associated with the merchant. This way, when the same credit card number comes through another merchant, a different unique token will be generated by the payment gateway. This will prevent some forms of credit card fraud by the merchant.
Uses for Unique Tokens
This cannot be used in every kind of transaction. Primarily this can be used for recurring transactions where the card is not present. For example, a fitness center (merchant) where the membership dues are charged to the credit card automatically every month. In this case, the merchant receives the credit card number from the customer and sends it to the payment gateway. The gateway will then generate a unique token, map it to the credit card number, store the credit card number securely and send the unique token back to the merchant. The merchant will store the unique token along with other customer information and discard the credit card number.
For subsequent transactions, the merchant can just send the unique token instead of the credit card number and the payment gateway can map it to the correct credit card to and forward it to the processor.
The biggest benefit is to the merchant who now does not have to bother with storing credit card numbers securely. The merchant just stores the unique token and resends that every time a corresponding credit card needs to be charged. This allows the merchant to concentrate on the business rather than worry about the technical aspects of PCI-DSS compliance. The lesser the scope, the lesser the cost of compliance also.