What is a Persistent Token?

If you accept payments online, you know the hassle that can come with handling sensitive data. While solutions like encryption can securely store data, encrypted data is often hard to utilize for internal business purposes. Tokenization, on the other hand, exchanges sensitive data for non-sensitive “tokens” that can be used internally without increasing scope for PCI compliance.

Tokens are pieces of data created to “stand in” for sensitive pieces of data. They represent valuable information for internal use while remaining harmless if stolen. If the original data is needed, the token can be “detokenized” and exchanged for the original data.

Tokens can be generated in formats that preserve valuable pieces of data, like the first six and last four numbers of a PAN (Primary Account Number), while masking the rest. This allows the tokens to be customized for internal use cases while remaining secure.

When creating a token for internal use, a particularly important distinction to consider is the difference between persistent and non-persistent tokens. How data is tokenized affects the created token and its potential business utility.

Persistent tokens preserve sensitive data’s length and formatting in a way that is consistent. This consistency means that if the same information is tokenized twice, the exact same token is created. So, a single persistent token can be used in place of its original data consistently across databases.

Persistent tokens solve the problems that some merchants face with tokenizing recurring information. Persistent tokens can secure recurring purchases, matching the order to the same account. They can also synchronize data being gathered and tokenized from multiple avenues.

To further understand persistent tokens, let us look at an example and compare the functional difference between a persistent token and a non-persistent token:

A merchant receives a payment online, and the data is tokenized with a non-persistent token. This token can be exchanged for original sensitive data if needed, but for now, it is kept for internal use. A week later, the cardholder makes another purchase on the same site with the same card. Another token is made, but because it is not a persistent token, its token is different from the first. These two tokens, representing the same card and same customer, are not connected, which can negatively impact internal analysis.

Looking at the purchase history for non-persistent tokenized card data would be complicated, if not impossible, given this scenario. Being unable to identify the purchases made by a single card number can significantly complicate internal analysis. Furthermore, making multiple tokens for a single card is inefficient and can increase the storage space used for tokens.

Let us look at the same purchases, but with a persistent token. The first time a card is used, a persistent token is created for internal use. Every consecutive purchase made with that card will use an identical token. This, functionally, will act the same as the original data as purchases can be easily traced back to the same card. Persistent tokens, then, enable both fluid payment processes and secure internal analytics.

IXOPAY creates persistent tokens that are optimized for internal use. Our flexible token schemes create data security solutions that secure data without compromising its utility. If you need a persistent token for PANs, or other sensitive data, talk to a IXOPAY rep today.