8 November 2017
Chances are, if you’ve heard of Apple Pay, then you’ve heard of tokenisation.
While mobile payments have cast tokenisation into the limelight recently, the concept isn’t new. In fact, tokenisation has been in use since 1976 (the same year as David Bowie’s Station to Station tour, not that the two are connected) for a variety of uses in data processing.
Mobile apps like Apple Pay and Android Pay have certainly breathed new life into tokenisation and made it a buzzy payments topic of conversation, but there’s a lot of confusion surrounding the functionality: what it is, the difference between tokenisation and encryption, the benefits of using token, business considerations and how it impacts your security.
Here’s a simple guide to everything you need to know.
What is tokenisation?
When you ‘tokenise’ an item, it means you’ve turned it into a completely different object. But the new object, while it looks different, represents the original item.
A common analogy to use is a game of poker, or any other game that uses chips as a replacement for money. The chips you play with, although they look nothing like money, represent it. It’s a lot safer to use chips instead of wads of money that might get stolen or lost, too. While the chips hold immense value during the game, once you leave the arcade or the casino, they mean nothing.
The same goes for card data.
Tokenisation removes sensitive card data, like primary account numbers (PANs), from your environment and replaces each number with a ‘token’.
The token is a long, unique string of characters that represents the original piece of data but has no actual meaning or value.
This is partly what makes tokenisation so valuable for businesses: if online fraudsters manage to steal your tokenised data, all they have a list of numbers that mean nothing. It doesn’t matter how hard they wish those numbers to turn into consumer card data, they never, ever will.
How do you pay with a token?
Typically, consumer credit and debit cards have 16-digit primary account numbers (PANs), an expiration date and a security code that’s found on the back of the card. Any of these pieces of information can be tokenised but let’s use the PAN as a simple example.
- Your customer enters their credit card number (PAN) into your eCommerce site
- Your eCommerce site sends the PAN off to be tokenised. This is usually done through your payment processor’s tokenisation system, like Bambora. If you’re not using a payments processor, it’ll go to your third-party tokenisation system
- The system then generates a string of 16 random numbers – the token - that replaces the PAN.
- The token, and its relationship with the original card data, recorded in a PCI compliant vault
- The token is then returned to your eCommerce site, and it now represents the credit card number
- The token is sent to your payments processor who uses PCI compliant technology to ‘unlock’ the token to view the original credit card number, and then processes the payment
Importantly, the token can only ever be unlocked once it reaches its final destination: the payments processor. But it was the token, not the credit card details, that was used throughout the transaction.
What’s the difference between tokenisation and encryption?
Both can be used to protect and transmit card data. So, here’s where it gets a little technical.
Encryption and tokenisation are often mentioned together as means to secure sensitive information that’s being transmitted through the internet.
Nowadays tokenisation is recognised as the more secure and cost-effective approach to handling sensitive card data. While there’s similarities, like they’re both a form of cryptography, encryption is different from tokenisation because:
- Encryption uses an algorithm to transform plain text information into a non-readable form called ciphertext. You need an algorithm and an encryption key to return it into its original plain text format
- Computer operating systems often use encryption capabilities to protect data and information, and there’s two ways to do this: symmetric key and asymmetric key encryption
- Symmetric encryption uses one ‘key’ to lock and unlock (or decrypt) data
- Asymmetric encryption uses two different ‘keys’ to lock and unlock data. For example, a merchant would have one key to encrypt payment data before sending it over to a payments provider for processing, and the payment provider would need the other key to unlock (decrypt) the data to process the payment
- Encryption doesn’t turn meaningful data like an account number into a random string of characters
- Tokens serve as reference to the original data and cannot be used to guess those values, because, unlike encryption, tokenisation does not use a mathematical process to create the token.
- Tokenisation does not use a key or an algorithm but instead uses a secure vault to store the relationship between the sensitive value (e.g. customer card detail) and the token
The bit that often trips people up is:
- The sensitive data in the vault is often secured through… encryption!
Why is tokenisation preferred over encryption?
It’s not necessarily preferred, but tokenisation is recognised as being the more secure process to protect cardholder data. Encryption is still incredibly valuable. It can be used to store structured (like card field data) and unstructured (like long documents) data as well as biometric data. It can also play an important part in validating cardholder identity online, so depending on the type and size of a business, there’s a good chance that you’ll leverage both.
Examples of tokenisation
In the payments industry, there’s three main types of tokenisation.
Card on file (enables subscription billing and recurring payments)
Single-click eCommerce functionality (pioneered by Amazon)
NFC digital wallets, like Apple Pay
The benefits of tokenisation
So far, we’ve looked at tokenisation from a pure security standpoint. But single-click checkout and NFC technology opens up an entire world of opportunity for businesses - and consumers.
How many consumers know that when they choose to store their card details, or when they use a digital wallet to pay, that this is a more secure way of paying – and why? It’s the convenience that tokenisation offers that’s driving the uptake of the functionality.
- Registering card details on your eCommerce site negates the need for consumers to re-enter them, speeding up the checkout process
- Single-click checkout encourages return custom, enabling a frictionless checkout, lowering shopping cart abandonment and promoting a better buying experience
- Digital wallets like Apple Pay, Visa Checkout and Android Pay offer businesses a competitive advantage: consumers can make a transaction in a single-tap, scan or fingerprint
From the standpoint of businesses and merchants:
- Tokenisation can reduce your PCI scope as it minimizes, and can even eliminate, the need for merchants to store payment card data. This is because you’ve eliminated or reduced the amount of sensitive card data in your back-end systems and replaced it with a token
- The growing use of ‘card of file’ models is accelerating token usage. This is especially prevalent in the mobile payments space where tokens can be stored in eWallets, negating the need for merchants to ever receive card details or PANs. This approach enhances the security of digital wallet payments and simplifies the buying experience on mobile or smart devices
- Tokenisation offers unparalleled protection whether you’re operating online or in a brick and mortar store
- Tokenisation not only works with plastic cards, but it also works with other types of payment, like gift cards. You can protect your customers' data no matter how they choose to send and receive money
Tokenisation and PCI compliance
It is a common misconception that if you’re accepting payments through a payment gateway, then your business is automatically PCI compliant.
This is not the case. PCI applies to all businesses who store, process or transmit cardholder information. How you manage your payment process will define the level of PCI that you must adhere to.
Tokenisation reduces PCI scope for merchants because you’re not storing, processing or transmitting cardholder data. However, the tokens and the system (the vault) in which they reside in will need protection and will therefore be in scope for PCI compliance to keep the data safe. Also, any systems connected to the secure vault will be in scope for PCI. To be considered completely out of PCI scope, both the token and the systems they’re on would need to have zero value to fraudsters who are attempting to retrieve PANs.
While tokenisation reduces your PCI scope, the roles and responsibilities that apply to the tokenisation solution as a whole should be distributed between the various stakeholders. The two main stakeholders are usually the merchant and the tokenisation provider (which might also be your payment gateway.) The level of PCI compliance you’ll need will be evaluated for every tokenisation implementation a business might do. For example, the location and flow of cardholder data, controls around de-tokenisation and mapping processes should be reviewed and verified every time to ensure proper scoping and appropriate application of PCI requirements.
If you choose to tokenise your payments through Bambora, you can be completely covered through our Level 1 PCI compliance solutions.
Is tokenisation right for your business?
From small businesses to large enterprise businesses, tokenisation can present huge benefits. It is suited to any businesses with subscription-based business models or merchants that generate significant business with repeat customers.
Sound like you?
If you’re interested in finding out more about tokenisation and what it could mean for your business, including PCI scope and requirements, feel free to get in touch with one of the Bambora team.
About the author
Victoria Galloway is Bambora APAC's Technical Copywriter, and has been writing and producing in the payments and eCommerce space for a number of years, both in the UK and Australia.