Although it has been in use on the American market for a long time, the concept of scheme token technology is still unknown to many German merchants. On the occasion of this year’s Europe-wide roll-out of scheme tokens by Visa, Mastercard, AMEX & Co., Computop gives an overview of all existing methods of tokenizing card payments and takes a closer look at the Scheme Token Services based on the EMVCo framework.

(Click here for part 2 of the article series: The Scheme Token Concept).

Tokenization briefly explained

In general, the process of tokenization refers to the exchange of a single data field (e.g., a credit card number or “PAN”) or a data set (e.g., all data associated with a credit card such as PAN, expiration date, holder name) for a meaningless, random string of numbers or letters. This arbitrary string of characters is called a “token.”

The token serves as a pseudonym for the actual data to be protected (e.g., card data). Usually, there is no mathematical connection (e.g., based on an algorithm) between the original data and the token. Thus, for all participants in the payment flow other than the token service, no reconversion of the token is possible.

A token service is responsible for generating, distributing, and managing tokens within a token system. The role of a token service can be filled by various actors, such as a payment service provider (PSP) or a card scheme (in this case, we speak of scheme tokens, see below).

The token service controls the token vault, the centerpiece of the system. At its core, the token vault is a database located on a secure server that stores the original data and the associated tokens. Here, the so-called “mapping” happens, i.e., the assignment of an initial value to a token.

As shown in the graph below, the tokenization process does not involve the transmission of card plain data between the sender and the recipient, but always just the respective tokens.

Tokenization vs. Encryption

Both tokenization and encryption are effective tools for protecting sensitive payment data. However, they are based on different principles.

During tokenization, the original value to be protected is exchanged for a new, random value (the token). At the end of the data transmission, the token is exchanged back to the original value and issued to the authorized recipient.

In the encryption method, the original value is not arbitrarily exchanged for an alias value but specifically encrypted by the data sender into a value that third parties cannot read. This transformation based on a mathematical algorithm is reversible, i.e., when the data is received, it is reversed by the data recipient with the aid of a required decryption key.

Encryption technology is always used in at least one or more places when transmitting card data on the internet. On the one hand, it takes place during the standard SSL encryption of the transmission path between the browser and the webserver. On the other hand (if tokenization is not applied), the sensitive transaction data (such as information on the payment card) is also encrypted by the responsible payment service provider for forwarding to the acquirer.

Why is tokenization used to protect card data?

Although encryption technologies are already a well-proven protection against card data theft in online and POS commerce, the alternative or complementary use of payment tokens offers several additional benefits for merchants:

• Tokens can be tied to a specific purpose. For example, the token service can set an expiration date or limit a token’s validity to one particular shop domain or one particular end device. Once the token is removed from its defined scope, it can no longer be used – unlike stolen card data.

• Merchants can store card tokens in their own systems without having to comply with a full PCI DSS certification. This bears considerable advantages, especially for regular customers: With a card token stored in the customer account, they do not need to re-enter card data for every subsequent purchase.

• Tokenized card data does not have to be completely unrecognizable. For example, it is possible to leave the last four digits of the PAN in the original. The front-end presentation of the token in the form of, e.g., **** **** **** 1234 enables the customer to recognize his card in his customer account and thus increases confidence in the payment process.

• By using tokenization, original data is never transmitted during data transfer. Instead of with all the actors involved in the transmission chain, the owner shares his information only with the responsible token service and the final recipient.

• A token system is organized centrally. While the technical prerequisites for data encryption must be individually implemented and supervised constantly by each actor in the transmission chain, the issuing, management, and exchange of tokens take place centrally in one place. Thus, tokenization achieves a greater degree of uniformity and efficiency.

How does tokenization come into play in online payments?

Credential on File (COF) via PSP Tokens

Most payment service providers (PSPs) offer their merchants a so-called credential on file (COF) functionality. Here, the PSP takes over the function of the token service.

If a customer places an initial order in the online shop using a credit or debit card, the card data is initially routed to the PSP via a secure payment page during checkout. If it is a one-time purchase (without registering as a customer in the shop), the PSP subsequently sends the card data directly to the acquirer in encrypted form.

If the customer also creates a customer account during the purchase, the PSP, in addition, sends a token to the shop backend. This way, the shop can store the card in the customer account without handling the actual card data. In return, the customer can make subsequent purchases and subscription payments without having to re-enter his card data with each payment.

When applying the COF principle in its simplest form, there is no complete tokenization across the entire payment process chain (see figure). With the use of PSP tokens, the card data merely “bypasses” the online shop, respectively the merchant’s systems, to save the effort of a PCI DSS certification and the associated investment in data security for the merchant.

Credential on File (COF) via Scheme Tokens

So-called scheme tokens can achieve full tokenization of the payment process for card payments in online shops or shopping apps.

Here, the role of the token service is filled by the card company (scheme) concerned. Readers can find a detailed description of the scheme token concept in article 2 of this series.

The customer’s card data is received in the shop checkout via the payment page hosted by the payment service provider (PSP). The PSP transmits the received card data to the relevant Scheme Token Service. The latter returns a token to the PSP.

If the customer makes a one-time purchase, one possibility for the PSP is to route the token directly into the payment flow. However, a so-called “tokenization during transacting” may lead to slower processing of the payment and affect the customer experience negatively. Therefore, many PSPs at the current stage of scheme token technology refrain from deploying scheme tokens for one-time purchases and stick to the conventional transmission of card data in this case.

On the other hand, if the customer creates a customer account, the PSP will transfer the token to the shop’s backend to be used for subsequent purchases. In this case, the flow resembles the COF-principle described earlier; however, the merchant bank (acquirer) as well does not get into contact with the original card data.

Mobile Wallets via Scheme Tokens

Mobile wallets such as Apple Pay or Google Pay also use token technology to protect their users’ card data from misuse and theft. Not only e- and m-commerce can benefit from tokens in this case, but also brick-and-mortar retail: Shoppers can use mobile wallets with stored credit or debit cards at POS card terminals supporting NFC or QR codes.

Like in the previous use case, the token service’s role is filled by the relevant card company (scheme).

If the customer deposits a card in the wallet, the wallet transfers the card data directly to the card scheme’s Token Service. In conjunction with the card-issuing bank (issuer), the token service returns a token to be stored on the end device used by the customer (usually the smartphone). This token is strictly bound to the device and can only be used when the device is unlocked.

If the customer purchases something in a shop that supports the wallet, only the token will be transmitted through the entire payment flow up to the card scheme (see figure below).

Interested?

Are you interested in the topic of payment tokenization? In the second part of our series, learn more about how scheme token technology works, as well as the benefits of integrating it into your shop.

Do you already have specific questions? Get in touch with us. Our payment experts will be happy to advise you on the use of Scheme Tokens in your online shop without any obligation.