Hello! Recently, at Yandex.Checkout, together with the Visa and Mastercard payment systems, we launched a new technology to tokenize payments for E-commerce, or, in other words, online commerce. Someone might think: what's wrong with the tokenization of cards already with the release of Apple Pay, Google Pay and other * Pay. But no, there is something new here, and we were also the first to launch this technology in Russia this spring for partner stores, so why not share it.
In the US and Europe, this technology appeared somewhat earlier, and users of services such as Netflix and Amazon already pay with E-commerce tokens, although they may not even know about it. And now I will tell you how it works not only outside (for partners and cardholders), but also inside, from the point of view of the developer and team lead of this project. If you are interested - welsh under cat.
Apple Pay Google Pay
, , Apple Pay Google Pay ( — *Pay), .
, *Pay , . , , . , , , . — — , .
:
- , ,
- .
? E-commerce, , - -.
, E-commerce
, — , .
— (PAN — Primary Account Number) .If the cardholder is the initiator to connect the card to * Pay, the online store initiates tokenization for E-commerce. But why (and why)?
Surely many of you use subscription services: be it monthly payments for music, movies, or, for example, utilities. How is this subscription issued? You go to the website of the online store, enter your card details and check the box confirming your agreement that the store will save your card details (PAN and expiration date) and will be able to initiate payment for a specific service on its own.
You need to understand that such an action implies that the store must save the card data somewhere. There are usually two options:
- , PCI DSS, -,
- , ., PCI DSS .
Is it possible to apply the tokenization approach here as well? Why not use some kind of token instead of storing bank card data, which can be managed separately from the card? But what if you make sure that the token remains the same with the next card re-issue and you don't have to re-link the card to different services? Sounds curious?
Let's talk about everything in order. During tokenization, we exchange bank card data for a certain token, but what is it? The token is provided by the card payment system - Mastercard or Visa. It is a unique identifier, similar to the device account number in Apple Pay or the virtual account number in Google Pay, which can be found in the application on the smartphone (Wallet on Apple devices and Google Pay on Android).
Unlike * Pay, in E-commerce tokenization, the creation of a token is initiated by an online store or its payment solution, and the tokens themselves are stored on the servers of payment systems.
Of course, anyone cannot come to the payment system and receive a token of someone's card to pay for purchases. Firstly, only payment solutions that are certified and receive payment system approval can tokenize cards. Such a payment solution is called On-Behalf Token Requestor or Token Service Provider, but for simplicity, we will henceforth use the term Token Requestor.... And only the Token Requestor can initiate token payments. Secondly, a token is always issued for a particular store, and with the help of a token you can pay only in that store. It is very similar to how the * Pay token is associated with the device on which it was created.
How is this achieved? It's just that before making each payment on the Token, the Requestor must obtain approval from the payment system for this payment. The fact of such approval will need to be presented during the actual payment, therefore this approval has the form of a one-time cryptogram, which is generated by the card payment system. When making a payment, this cryptogram is added to the request parameters in the acquiring bank and then transmitted to the payment system, which verifies the authenticity of this cryptogram, which itself previously issued.
And what about token management, regardless of card management? In general, everything is simple here - the token lives its own life, has its own life cycle statuses, and the Token Requestor immediately learns about each change in the status of the Token Requestor from the card payment system.
Let's summarize. What does tokenization give to the cardholder?
- The safety of real bank card data. When making a payment, a token is used, and the card data itself is not transmitted, so a potential attacker cannot intercept them. And there is no point in intercepting the token data, because the token turns into a pumpkin when you try to pay in any other store.
- When a bank card is reissued, the token issued for the online store continues to be valid, and the cardholder does not need to link the new card to the services he needs.
- The ability to control the token. Tokens can be managed without affecting the bank card itself. Issuing banks will be able to implement special tools in their interfaces for the flexible management of bindings in online stores (creating a token in a new store, viewing existing tokens, removing irrelevant ones).
What does it do for online shopping?
- What's good for the shopper is good for the store too, so using tokenized cards can increase customer loyalty.
- , . , , . , .
- . , . , 88,53%, 97,89%*. , - , - . . , -, , .
* We compared payments for this April in a large online cinema (MCC 4899) - linked cards without 3DS, excluding unsuccessful payments due to lack of money on the card.
Technical aspects
For those who like to dig a little deeper, I’ll talk about the technology of card tokenization and its launch in Yandex.Cash - what it all looks like from the inside of our payment solution.
Integration with payment systems
To get the technical ability to tokenize cards and make payments with tokens, you need to integrate with Visa and Mastercard, pass tests, certification and get their approval for launching in production. At first it sounded intimidating. And not only at first, to be honest, at least for me. But the certification was more frightening, and in terms of technology everything was very clear.
Integration implies the implementation of the following API (conditionally) between the payment system and us as a Token Requestor:
- .
-, . (risk scoring) . , , , . , . - .
, : — , ? , , . , , . - .
/ , , , , . , .
This description of the API is conditional and generalized - it is easy to guess that each payment system has different request / response formats, signature and encryption algorithms for data in requests, and there are various nuances in business logic. Therefore, we hid all these details and differences from the rest of our system by creating a separate card tokenization service, which is an adapter to payment systems and is fully responsible for the life cycle of tokens.
Tokenization in Yandex.Cash
Yandex.Checkout is a large system for accepting payments for online stores. It consists of dozens of different services: backend, frontend applications, BI services. They provide acceptance of the user's payment in various ways, transferring funds to the store, managing payments through the store's personal account, analytical services, and the like. And how exactly did card tokenization come in here?
The main question is: when to create a token for a bank card?
The Yandex.Checkout API allows you to save the selected payment method for future payments in the future, we call this auto payments .
This can occur both when the card is linked to the user's account in the personal account of the store, and when subscribing on a periodic basis, when payments from the card will be made automatically. In both scenarios, when creating a payment, the merchant uses the API to pass the save_payment_method: true parameter , and after a successful payment, we issue the merchant payment_method_id - the identifier of the saved payment method, with which it can make new payments.
Here it is, this moment. Tokens are created just for payments initiated by the store. Therefore, immediately after making a payment while saving the payment method, we asynchronously set our tokenization service to create a token for the “card and store” pair.
What do the payment systems themselves do when the card is tokenized?
They contact the issuing bank with a request to create a token (as happens when creating * Pay tokens), and the bank issues a token for this store. The bank can also notify the cardholder about this and display the created token in his personal account.
How is the token payment made?
Perhaps, you will need some illustration here, how the payment with the previously saved card that initiates the online store generally takes place:
So, when paying with the previously saved method, the store transfers only its identifier - payment_method_id . Using this identifier, the card payment service finds the data (PAN and expiration date) of the card and transfers them to one of the acquiring banks, which then communicates with the card payment system.
With tokens in this scenario, one more step is added:
If we see that a token was previously issued for the card and the store, then we can make a payment without using the card data. To do this, through the tokenization service, we first send a request to the international payment system with the token data and in response we receive a one-time cryptogram, which confirms that the token is valid and we have the right to make a payment. And after that, we transfer the token bank data along with this cryptogram to the acquiring bank.
And what happens in the scenario when a user reissues a card in his bank?
If tokens were previously issued to the card, the issuing bank informs the Mastercard / Visa payment system that the card has been reissued. In turn, each Token Requestor that issued tokens to this card will receive a notification from the payment system. It contains updated information about the card: the last 4 digits of the number and the new validity period. The token remains the same.
When a store initiates another payment from an already expired card, which was actually reissued, and we have a token for it for this store, the payment will be successful. In addition, we will inform the store about the new last 4 digits of the bank card - they will be present in the responses of our API. This is necessary so that both the store and the user can always see from which card the funds are debited.
Instead of a conclusion
Tokenization in E-commerce is a new stage in the development of payment acceptance, increasing the convenience for all participants of the payment process. We expect that in the near future the technology will be supported by many Russian banks and providers - and it will become a new standard in the payment market.
Of course, the story turned out to be more of an overview, but I hope that every reader will find something useful in it - increase their level of financial literacy, learn about the latest in fintech, or maybe find an idea for developing their business.
I'm done, be healthy and don't get sick!