This article belongs to the mini-series providing guidelines for merchants interested in attaining PCI compliance. In this installment we are going to cover the approaches to credit card tokenization and possible solutions that make PCI audit more attainable.
If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.
Credit card tokenization concept
The idea behind tokenization is to delegate credit card storage to the payment gateway or payment processing system, as opposed to business-specific software, such as web-site, online storage or CRM. The main purpose of tokenization is to allow merchants not to store credit card numbers for repeated\recurring transactions. To achieve this, credit card numbers are replaced by tokens which are saved and used instead.
Fundamentally, there are two primary approaches to tokenization.
Approaches to credit card tokenization as a process
The two conceptual ways to implement credit card tokenization are commonly referred to as pure tokenization and profiling.
Pure tokenization
Under pure tokenization approach, only credit card (bank account) number is tokenized. However, if necessary, routing number (identifying the branch of the bank) for ACH, social security number, or even driver license number, could be tokenized as well. To put it simply, every sensitive value is replaced by a token (one for one).
When the credit card processing request is issued (during repeat\recurring transactions), the token is used instead of a credit card number, allowing merchants to avoid credit card storage.
Profiling
The second approach to credit card tokenization (profiling) is a bit more elaborate, as it involves maintaining the full or partial customer profile.
The difference is that in this case the entire billing information, including the billing address, shipping address etc (depending on the system used) would be stored in the customer profile (including credit card number). When a transaction is processed, the ID of the profile is sent, and any fields that are not supplied, are “pulled” from that customer profile.
Some systems use a variation of customer profiles where instead of customer profile an ID of the previous transaction is passed and all of the missing information, such as credit card number etc, is extracted from that transaction.
When repeated\recurring credit card transaction is processed, the profile ID (or ID of the previous transaction) is used in place of the actual credit card number, thereby allowing the merchant to avoid persistence of the credit card number.
Advantage of the first approach is that the business doesn’t have to do any separate maintenance of the profile. It only has one number and the token just replaces it. Advantage of the second approach is that more information can be stored outside of the merchant’s system (web-site\CRM). Consequently, if the merchant has some basic front-end system and doesn’t wish to store all the billing information (ZIP code etc), it can rely on tokenization provider to store that information, which might be more convenient for the merchant. However, with this approach the merchant assumes the responsibility for keeping the profile up to date.
Now let us look at the most common ways to implement credit card tokenization.
Credit card tokenization through appliance
Tokenization through appliance is intended for the pure tokenization approach, described above.
The appliance is a combination of a hardware device (used to encrypt\decrypt credit card numbers) and PA-DSS-compliant software (used to store encrypted values and to generate tokens). The hardware device is usually either a chip on the motherboard or a PCI-card. The appliance (hardware with software written on top of it) is hosted in local network of the merchant\PSP.
Hardware\appliance solution does not eliminate the need for PCI-compliance certification, but it definitely reduces the scope and simplifies the PCI audit, as the storage is delegated to an already PA-DSS-compliant piece of software.
Credit card tokenization through appliance can be an ideal solution for a merchants\PSPs processing large volumes of transactions and already having an existing PCI environment where the appliance could be deployed.
Credit card tokenization as service
The other approach is hosted tokenization service, where, instead of having some type of device in merchant’s own network, the merchant is delegating storage to some other (third) party. In this case the merchant must use some form of API to generate the tokens.
When it comes to credit card tokenization as service, there are 3 conceptually different approaches with minor technical distinctions, nevertheless, important and worth noting:
- Processor-integrated tokenization – tokenization is an integrated service of the payment processor. The advantage is that the merchant only deals with one and the same party for credit card tokenization and processing. In order to process a transaction there is no need to de-tokenize credit cards (or even to “touch” the actual card number, because it is stored by the underlying processor). If a token is already obtained by the merchant, when transaction is processed, the merchant simply passes this token to the processor and the processor is able to locate the respective credit card number. Under this approach switching to another processor would result in costly data extraction and re-location procedures. And data extraction fees are sometimes really heavy.
- Gateway-integrated tokenization – the approach is similar to processor-integrated tokenization, except that tokenization is handled by and independent gateway (possibly, servicing several processors). The advantage of this approach is that if a merchant switches from one processor to another (serviced by the same gateway) the tokenization procedure remains the same and costly re-tokenization process is not required. Under this approach the merchant does not touch the card data, remaining completely out of PCI scope.
- Third party tokenization – cards are stored by the by the third party separate from the one who processes transactions. The merchant uses the API to tokenize/detokenize cards on demand. This option is a little less secure, because although the merchant doesn’t store card number, before it processes the transaction, it has to de-tokenize the transaction, take the actual number and send it to the processor. The merchant is touching but not storing the card number. So, this solution reduces the merchant’s PCI scope, but does not take the merchant out of it.
The next and concluding post in this mini-series will cover payment card data flow and respective solutions allowing merchants to reduce or even get out of PCI scope.
Recommended to you
