Digital Payment Overview
A card number that can pay, but with only limited usage
Payment cards typically have 16 digits embossed on the front of the card. This is the so called Primary Account Number, PAN. The PAN is transferred from the card to the terminal and from the terminal to the payment network as the card is swiped through, inserted into or tapped onto the payment terminal. As e-commerce payments emerged at the end of the 1990s, it was necessary to find a way to transfer the PAN without a terminal. The solution was to simply let the cardholder manually enter the PAN (and the expiry date and card validation value, or CVV) in a payment page on the e-merchant's site each time the cardholder pays, a so-called "Card Not Present" (CNP) transaction.
As e-commerce continued to grow, Cards On File solutions emerged. Cards On File means that the e-merchant urges the customer to create a user profile, including the PAN (and the delivery address). After having logged into the e-merchant's store (with their username), customers don't need to manually type the PAN and delivery address once they have selected the goods they wish to buy. The e-merchant (or rather the payment service provider of the e-merchant) simply uses the PAN (stored on file) corresponding to the user profile. Consumers embraced this convenient process, and Card On File solutions quickly became very popular.
But what if the e-merchant didn't store the "real" PAN, but a number (a token) that Visa/MasterCard has linked to the PAN? This number (the token) would look exactly like a PAN, and several tokens could be linked to one and the same PAN. Every individual token could be assigned a limited usage, e.g. token no. 1 only works with e-merchant x. Hence, if token no. 1 were to be compromised it could only be used to pay for goods shopped from the store of e-merchant x. That means that the extent of any potential misuse would be significantly reduced compared to having a real PAN (that could be used to pay for goods from any merchant anywhere in the world) compromised.
Enabling the payment instruments of tomorrow
In recent years, there has been an explosion in the number of ways we pay in Cards On File mode. Think about apps such as Uber and 1-click merchants such as Amazon. We don't pull out our payment card to pay the Uber driver via a terminal in the taxi; Uber "invisibly" charges our card (which Uber has stored on file) and we just step out of the cab once the ride is over. Soon, our fridge will order and pay for milk and our car will book and pay for 10,000 km service without any intervention from our side, as the Internet of Things (IoT) becomes mainstream for numerous objects of our everyday life. And if one token can be used for our fridge (and this token will only be able to pay if it's used from our fridge), another token for our car, a third for our Uber app, a fourth for Apple Pay and so on, all these objects can be turned into payment instruments in a very convenient and secure way. And the existing payment infrastructure can cater not only to the payments of today, but to the payments of tomorrow as well.