Payment Concepts: Credit Card Tokenization

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.


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.

Payment Concepts: PCI Compliance

The purpose of this mini-series of articles is to familiarize small and medium-sized merchants with the concept of PCI compliance and with available solutions allowing them to reduce their (or even get out of) PCI scope.

What is PCI compliance about?

With the advance of credit card processing technologies, the scales and types of credit card fraud also witnessed considerable extension. To prevent manipulations with credit card data during credit card processing, Payment Card Industry Compliance (or PCI compliance) requirements were introduced (more detailed info can be found here).

While there are many businesses wishing to accept and process credit cards, relatively few are equipped with all the tools and resources necessary to meet strict PCI certification regulations. As a consequence, there are some solutions available to smaller and medium-size merchants, allowing them to get out of PCI scope or simplify their PCI audit (reduce their PCI scope).

Before moving to detailed coverage of these options, it would be appropriate to list the key PCI compliance requirements that are defined and maintained by PCI Security Standards Council (PCI SSC).

PCI standards

PCI DSS stands for Payment Card Industry Data Security Standard. The standard specifies the requirements to be followed by an organization, dealing with payment cards. These requirements are primarily meant to ensure credit card data protection and prevent security violations. Any business wishing to attain PCI compliance must follow the PCI DSS standard. Requirements and objectives to be followed by businesses, according to PCI DSS, can be found here.

In addition to PCI DSS standard, concerning PCI compliance of businesses operating with payment cards, there is a more concise standard for payment card processing software, called PA DSS (Payment Application Data Security Standard). PA DSS lists the requirements to be met by payment processing applications in terms of cardholder’s data protection. The complete list of PA DSS requirements can be found here.

To keep track of all PA DSS compliant applications a special list of Validated Payment Applications is maintained by PCI SSC.

In a nutshell, PCI DSS is targeted at businesses that accept credit cards (such as retail stores, health clubs, collection companies and others) and those that offer payment applications in hosted mode (such as payment processors, payment gateways and e-wallet companies).

PA DSS, on the other hand, is targeted at software packages, manufactured by companies, which do not necessarily operate with payment card data themselves, but software products of these companies are distributed to end users (who do process credit cards) and installed on their machines (or in their networks). In general, PA DSS requires these products to ensure security of payment card data processing.

More information on standards and other PCI SSC documents can be found here.

The two components of PCI compliance

At the high level, businesses that deal with PCI compliance face two issues:

  • Cardholder data storage – should credit cards be stored, how should they be stored, who is going to bear the liability for storing of the cards.
  • Cardholder data flow – at which point a credit card is accepted, swiped vs keyed card processing, which software is used to process credit cards, how the card gets persisted.

While it is generally understood and accepted that storing cards puts a merchant in PCI scope, people often tend to misunderstand the concept of card flow, thinking they are not in the scope, while actually being in it.

In the subsequent articles, we are going to present some guidelines to follow while evaluating your card storage strategy and general card data flow, and provide suggestions on how to make PCI compliance more attainable and PCI audit – less labor-intensive.