Tokenization

Payment card tokenization is the process of taking some sensitive data, the card number (Funding PAN) and representing it, in a non-sensitive way through a token.

The reason for tokenization is to minimize the PCI DSS scope. Any interaction with card numbers require that the involved systems are located in a PCI DSS environment. Tokenization enables identification through systems that are not in PCI DSS scope, for example merchant ECR systems.

The main purpose of tokenization is to keep systems out of PCI DSS scope and therefore the token cannot contain or be derived from PAN. PCI DSS specification says that any system that operates on data containing card data (even if is encrypted) is an adjacent system and thereby in PCI DSS scope.

A hash function is defined as a one-way function, i.e. you cannot get back to the original value. It is however highly discouraged use a PAN hash as a token, even if it is salted with a cryptographically secure value.

Token usage

There multiple uses for tokens, generally speaking there are two different types, payment tokens and identification tokens.

EMV Tokenization (payment token)

Used by wallets like ApplePay and GooglePay where a card is virtualized and a Token PAN is issued which is then used in the payment network.

The purpose of EMV Tokenization is security and to avoid fraud, but not identification.

Non-payment tokenization (identity token)

Non-payment tokens have no connection to the payment network, i.e. they cannot be used as a means of payment, but they can be used for identification. This is the type used by Storebox.

The flow is split in two, one for registration and one for usage.

Step 1 The user registers a card in Storebox. Then the card number is tokenized in all supported Payment Applications (PA) / Payment Service Providers (PSP).

Step 2 At the till, the ECR can request or retrieve the token from the terminal / PA and use it for the relevant VAS, for example digital receipts or loyalty.

Pre-purchase

There are two times in a payment flow where (identification) tokenization may be needed, before and after the transaction.

Before a purchase is finalized the merchant may want to know if a customer has vouchers or loyalty points that may cause the total amount to be lowered. In this case the tokenization has to happen before the payment is captured.

Token Service / Card Vault

To implement pre-purchase tokenization, a card vault may be used. The vault is in PCI DSS scope and basically maps the card number to a random value, i.e. the token.

The concept is that the ECR requests a token through the terminal, which then communicatess with the card vault to translate a sensitive value, the card number, to a non-sensitive value, the token.

The token is then used to interact with the Value-Added Service (VAS), like digital receipts or loyalty.

Examples

NETS Viking

An example of how this is done using NETS Viking terminals and Baxi can be found here.

In-purchase

In-purchase, refers to the time in the payment process, where the actual transaction is done and the user is finishing the purchase.

Tokens after the purchase cannot be used modify the transaction, for example change the amount, since the transaction is already captured. It can however be used for VAS, like digital receipts or level-based loyalty.

Where pre-purchase tokenization requires an extra request to the implementing application, in-purchase token can be returned to the payment/transaction response.

PAR

Even though using a card vault-based token, in the payment response, is a viable solution, there is actually a standardised value that can be used as a token, PAR.

PAR (Payment Account Reference) is EMVCo standard, which is meant to solve the problem with EMV Tokenization where you don't know the Funding PAN (FPAN), since each virtualized card gets in own Token PAN (TPAN).

PAR is a non-sensitive representation of the FPAN and all the derived TPANs, which means that any TPAN has the same PAR as its FPAN.

The PAR value is available in the authorization response in field 56 of the ISO-8583 message. It is added by the PAR BIN controller, which usually is the card scheme.

NOTE Technically the PAR may also be available on the NFC chip and thereby available for pre-purchase identification, however there are currently so many caveats with this, that it is out of scope of this document.