In 2021, Visa, Mastercard, AMEX & Co. will introduce the Scheme Token technology for e-commerce card payments on the European market. As a certified Scheme Token Service Provider, Computop explains how Scheme Tokenization works and what its advantages over other tokenization concepts are.
- More convenience when paying by credit card on the Internet
- Higher conversion rates thanks to Scheme Tokens
- More security for merchants and customers
Briefly explained: What are Scheme Tokens?
Scheme tokens (also network tokens) are used to process card payments in e-commerce and mobile wallets (like Google Pay or Apple Pay, enabling payments also in brick-and-mortar shops). The card company (Scheme) fills the role of the token service and manages the token system. This architecture ensures end-to-end tokenization of the payment flow from the merchant to the responsible Scheme.
Like the credit card wallet Click to Pay (see here), the Scheme Token technology is based on a unified set of technical rules defined by EMVCo. EMVCo is the international association of the six leading credit card companies Visa, Mastercard, American Express, Discover, JCB, and China Union Pay.
The development of the Scheme Token concept aims to make online payments by credit and debit card even more secure and easier for consumers while at the same time achieving similar authorization rates as in stationary retail. To this end, in the future, shoppers’ card data – such as the card number (PAN) – is to be kept out of the online payment flow as far as possible. The physical card will be replaced by the Scheme Token (sometimes also referred to as the Network Token), which has several additional advantages over already established gateway token systems (see below).
Use of Scheme Tokens in Online Retail
Scheme Tokens solve a fundamental problem for online merchants who accept credit and debit cards in their online shops. Storing card data in their systems is only possible with a valid, fully comprehensive PCI DSS certification. However, obtaining such a certificate involves considerable effort and additional investment for merchants.
The use of Scheme Tokens eliminates this requirement: The payment method “credit or debit card” can be stored as a token in the customer account (and thus in the shop’s backend). Returning customers do not have to re-enter their payment data for subsequent purchases. This technical option is also known as Credential on File (COF).
The following descriptions refer to the use of Scheme Tokens in online shops and shopping apps. You can find a description of Scheme Tokens in mobile wallet systems and explanations of the basic functionality and general advantages of tokenization in part 1 of this series.
The architecture of a Scheme Token Service
Although EMVCo has defined a uniform technical standard for its associated card companies (Schemes), Scheme Tokenization is no centrally organized system. Each Scheme operates its own Scheme Token Service. Depending on which card brand (e.g., Visa or Mastercard) the customer uses for payment (see Figure 1), the payment service provider of the merchant addresses the responsible Scheme Token Service.
- Unlike other token systems (such as gateway token systems, see here), the Token Service – and thus the central control unit of the system, including the Token Vault – is always owned by the respective Scheme. The Scheme Token Service is responsible for creating and managing the tokens and performs the matching of tokens and the associated card data during transactions.
- The Token Requestor is the online shop or shopping app of the merchant that requests the token as a replacement for the card used by the customer. If the token is used in a mobile wallet system, the token requestor is the wallet operator. In some instances, the merchant’s payment service provider can also take on the role of the token requestor (see the chapter on implementation options).
- The Token Service Providers (TSP) are the interface between the a) Scheme Token Service and the Token Requestor and between b) the Scheme Token Service and the issuer bank. Their tasks include the initial onboarding of the merchant and the issuer banks on the Scheme Token system, the transmission of tokens, as well as the so-called lifecycle and card art management (see chapter “benefits”). The role of the Token Service Provider is not performed by the card company itself but by certified third parties. The TSP responsible for the merchant (i.e., the token requestor) is usually the merchant’s payment service provider.
The Scheme Token Payment Process
How is a Scheme Token created?
When a customer buys from an online shop for the first time and creates a customer account, he or she submits his or her card data to the merchant’s payment service provider (PSP) via a payment page part of the checkout or registration process.
To request the token, the PSP simultaneously forwards the card data to the relevant Scheme Token Service (e.g., the Visa Token Service in the case of a Visa card). The token service informs the relevant card-issuing bank (issuer) about the token request and, after the issuer has given its consent, replaces the card data with a token. The token requestor then receives the token to deposit it in the cardholder’s customer account.
How is the transaction of the initial purchase handled?
The PSP forwards the card data to the merchant acquirer to complete the initial purchase via the regular transaction procedure for online card payments (without tokenization). This approach is chosen because, in conjunction with an ongoing transaction (tokenization during transacting), the request and creation of a token minimally slow down the payment and lead to a bad user experience.
How does the Scheme Token come into play for subsequent purchases?
Once the Scheme Token is deposited in the shopper’s customer account, the Token Requestor can use it for subsequent purchases and subscription payments. For this purpose, the shopper needs to log in to his customer account.
The flow of payment data and authorization notifications is shown in the chart below.
Scheme Tokenization and 3-D Secure 2
Online card payments processed via Scheme Tokenization are also subject to the 3-D Secure 2 protocol. Once a token reaches the Scheme’s Directory Server, it is forwarded to the Scheme Token Service, which renders the corresponding PAN. From there on, the 3DS2 procedure takes its normal course.
What are the benefits of Scheme Tokens?
No PAN in the payment flow
Since the card company itself performs the role of the token service, Scheme Token systems reduce the contact of the card clear data with the actors involved in the payment flow to a minimum. Unlike gateway token systems, the acquirer also only comes into contact with the token. The only points of contact with the PAN are thus the token service provider (as part of the system) and the Scheme and issuer (who have the PAN anyhow). This makes it virtually impossible to steal the actual card data.
Reliable cardholder authentication
With every initial token request, various data on the cardholder, transaction, and customer account are transmitted to the issuer – comparable to the 3-D Secure 2 process. The data ensures the correct verification of the cardholder and enables a well-founded risk analysis of whether a token should be issued for the underlying card.
Smart Token Principle
Scheme tokens are so-called smart tokens. This means that the properties of tokens already created can be modified without the need to issue a completely new token. The principle becomes manifest in the following technical features: Lifecycle Management, Card Art, Domain Control, and Token Cryptogram.
Lifecycle Management
Each Scheme Token System includes a so-called “Lifecycle Management,” which – with the help of the Token Service Provider – enables an exchange of information between the token requestor (merchant), token service, and issuer (see figure 1).
For example, the merchant can instruct the token service to pause a token, reactivate it, or delete it altogether.
In turn, card information coming from the issuer bank can also be considered directly. Suppose the card associated with the token expires and is renewed. In that case, changes like the expiration date, PAN, cardholder contact information can be updated directly in the Token Vault of the token service without creating a new token.
Also, if the issuer detects suspected fraud in connection with the token or the card itself, a deactivation of the token can be initiated immediately.
Scheme tokens replicate the look and feel of the actual card
Merchants can obtain the appropriate “Card Art” for a token from the relevant token service, i.e., information on the actual visual appearance of the physical card. The cardholder sees an authentic image of his card in the design of the issuer bank in his customer account. This creates a higher level of trust in the payment process. In addition, the image contains the cardholder’s name and the last four digits of the PAN.
Linking to specific domains and end devices
As effective protection against theft and misuse, the token requestor (merchant) can restrict a token to specific store domains or individual user end devices. When requesting the token, the merchant must provide the Scheme Token Service with the necessary data such as domain address, device ID, and device properties.
The cryptogram: Linking the token to specific transactions
As additional protection against fraud, token validity can also be limited to individual transactions without the need to request and create a new token after the transaction has taken place.
Before the actual authorization request for a token transaction is made, the merchant first requests a Token Cryptogram from the token service, which contains the attributes defined for the current transaction, such as an individual session ID or a specific validity duration. The cryptogram itself is encrypted and can only be read by the token service and the issuer responsible. All other actors, on the other hand, are not able to subsequently change the cryptogram.
After the merchant’s shop has received the new cryptogram, it is submitted into the payment flow together with the actual token, from where it finds its way back to the token service and the issuer. By checking the cryptogram, token service and issuer can ensure that the authorization request came from the store in question and was not triggered due to a “replay attack” based on a stolen token and a “used” cryptogram.
How can I obtain Scheme Tokens as a merchant?
All essential steps for Scheme Token implementation into an online shop are taken by the responsible payment service provider (PSP). Merchants must therefore check with their PSP whether it supports the technology and should note the following points.
- If possible, the PSP should be an approved Token Service Provider (TSP) itself and not use a third-party provider as a Token Service Provider. A solution purchased by the PSP does not lead to any disadvantages in terms of security and performance. However, the involvement of an additional technology provider can lead to increased integration efforts. In addition, the service must be “bought in” by the PSP itself, which often leads to higher service fees in the end.
- A TSP certification always refers only to a specific Scheme Token Service. For example, if a PSP (in its role as TSP) is only certified for the Visa Scheme Token Service, the merchant can only obtain Scheme Tokens for Visa cards. For this reason, the merchant should ensure that the payment service provider has appropriate TSP certifications for all those schemes whose cards are accepted in the online shop.
I already use Gateway Tokens as a merchant. What options do I have?
The chart below provides an overview of the merchant’s options when using tokens for COF card payments.
The introduction and widespread implementation of Scheme Token technology in Europe is a central part of the e-commerce agenda of the EMVCo card companies. With that said, it is only a matter of time before every major payment service provider either becomes a Token Service Provider itself or provides the service via a technology partner. The classic COF implementation using only gateway tokens is thus becoming a discontinued model.
It will be replaced by the hybrid integration option outlined above or the exclusive use of Scheme Tokens across the entire payment flow. Most payment service providers will probably offer their customers a “hybrid solution” for the indefinite future and further employ the gateway tokens already implemented. Nothing would change for the merchant since the contact point to the Scheme Token Systems lies solely with the PSP, which additionally would act as Token Requestor in this case.
Interested?
Do you have any questions? Get in touch with us. Our payment experts will be happy to advise you on the use of Scheme Tokens in your shop without obligation.
