What is Tokenization?

If we were to put it in very broad terms, tokenization consists in the replacement of sensitive and/or private data with a randomly generated value (token).

I think I’ve heard about it. Is it the same as encryption?

Not quite… Encrypted data is nothing more than the actual (sensitive!) data after a transformation algorithm is applied to it. But even if protected with a million encryption algorithms, the private data you’re trying to hide is always there for you to access, given that you know the encryption keys.

With tokenization, on the other hand, the token and the original data don’t have any correlation at all. In fact, if one would generate multiple tokens representing the same data, those tokens would all be different, given their completely random nature.

Hmm… It seems much more secure to use tokenization rather than encryption…

They both have their pros and cons, and in many cases, one does not replace the other.

Imagine you’re dealing with a micro-services based software architecture (I’m getting a bit technical here, I know, but please, bear with me), and you handle sensitive data that needs to be referenced all around the platform, but only needs to be actually accessed by one platform component. That one component can safely store the sensitive data locally, and link it to a random token that is sent to all the other components. These other components, which don’t need access to the original sensitive data, can use the token without any special security concerns, because the token, per se, doesn’t contain any private information. This type of mechanism can, for example, greatly reduce the risk of critical data leaks, by allowing a development team to focus its security concerns on a very limited part of a platform.

Below is an example of such architecture, in which a payment card number (PAN) is handled by one piece of the platform, and tokens are used by every other component.

Credit Card Tokenization

Now that we have established the concept of tokenization, let’s talk about what has triggered it into the payments world: card payments. Tokenization has taken a big part in the online payments world for long. Since the early 2000s, there have been companies offering card tokenization to online merchants.

When we’re talking about e-commerce payments, card tokenization is pretty simple to understand if you got the tokenization concept right: instead of dealing with the actual card’s Primary Account Number (PAN), merchants deal with a token that replaces it.

For online businesses, having access to a tokenization solution is nothing but beneficial. The obvious use-case for tokenization is allowing users of a given platform to store their payment card information for later use. When you allow your users to do this, you’re betting on the chance they’ll come back, and if they do, you’ll greet them with a smoother payment experience (not having to enter the card details is great, people hate having to fill in forms), which will most likely make them come back more often.

Besides helping businesses to achieve higher conversion rates, tokenization also enables other types of payment mechanisms. The clearest example is the subscription-based business model. What would you think of your streaming service of choice if they’d make you enter your payment card details for every monthly charge? By now you may be wondering why isn’t all this possible by just storing your users’ card details, instead of using some tokenization service. That’s a pretty legitimate question to ask. But believe it or not, storing those card details isn’t as simple as it may seem…

If you work in the payments industry and deal with card data on a daily basis, you probably know this and, if you don’t, you can take my word for it: not having to store sensitive card data is great! Why? You don’t risk leaking a database full of card numbers (no one will steal from you something you don’t have). You won’t spend countless hours making your operation PCI compliant: PCI certification is required by card brands for merchants that process card payments and this certification’s thoroughness increases according to the merchant’s processing volume and how they interact with the sensitive data.

Taking Tokenization to the Next Level

Tokenization most commonly consists of storing users’ payment card information for later usage. But what about the other hundreds of alternative payment methods out there? If you own a business, you’re most certainly interested in offering your customers as many payment methods as possible, in order to maximize your conversion rate.

Switch’s tokenization solution brings all the benefits of tokenization to each and every payment method supported by our platform, in the form of Vaults.

Vaults offer merchants the possibility of aggregating every single piece of information relative to a user in a single token. This means that a token can include user personal details and any payment method authentication parameter that you may ever need to collect from your customer. Name, address, date of birth, phone number, VAT number, bank name, bank account number, … In short, any parameter of the Switch platform can be stored in a Vault.

And don’t worry, you won’t need to collect every single field possible at once. You can ask your customers these details each time they use a new payment method, and update that customer’s Vault accordingly. Eventually, you’ll have tokens that include enough data to avoid the need for further input from your customers at the checkout moment, and still, allow them to use their favorite payment methods.

Also, at any time, you can delete your customer’s data, either because a payment instrument has expired, or to comply with any personal data policies you may be subject to.

In short, Switch Vault offers businesses the chance to maximize their conversion rate while enabling them to safely store sensitive data without any concern. But there’s actually more to it:

• Using more than one payment provider? You can (and should) store tokens in a single vault controlled by you, so you’re able to reuse them across your provider base and capitalize on our Dynamic Routing application to optimize acceptance and processing rates.
• Accepting payments in multiple channels? You can adopt a true omnichannel payment operation, leveraging the Switch Terminal Application to initiate a transaction in-store and continue it online e.g. allowing your customers to pay in-store and request a refund on your website.