How we made payment via Google Pay at Yandex.Cash [updated]

When Google Pay just appeared in Russia, I started an account, added a card there and realized that I could not do anything else. NFC wasn’t on my phone, there’s nothing to pay on the Internet either — well, okay, it doesn't bother me. In the end, you could always use your hands to drive in numbers from a card or pull them up from the browser password store.

Then I looked at how the various people who stood in front of me in line were paying with a smartphone; then I saw ads and discounts for using Google Pay everywhere, but I still could not use it - I still went with a phone without NFC.

And now it is today. Now I can pay via Google Pay from any device on sites that are connected to Yandex.Kassa (and there are quite a lot of them). I'll tell you how it happened and what technical problems our developers had to solve; there are many interesting things both at the front and in the backend.

Just add the API

- Comrades, the developers, and what was difficult there?
- Yes, we just added a library from Google on their docks.

That was the first minute of my talk about adding Google Pay with the developers of the Cashier (including 55 seconds of awkward silence). But then I was not taken aback, and we found out a few amusing things.

Google Pay is changing the card payment process.

Now through the cashier you can pay with any credit card, even overseas. As with any card payments online, it is not always convenient - sometimes you need to go for a wallet, drive numbers in the dark and check that nothing is confused anywhere. To make life easier, you can log in to Yandex and pay with attached cards.

We implemented a scheme in which card payments through Cashier became unified and well documented. If you remove all the subtleties of routing and security nuances, the scheme looks like this:

1. The user selects the product, places the order and goes to the Yandex.Cashy payment form. There you can enter the details of any card or log in to Yandex to see more of your attached cards.
2. Data on the selected payment method go to the backend for tokenization. The browser receives the card token and tries to use it for payment.
3. If everything is in order, the backend asks the bank to block the amount on the card, makes a payment and returns its status. Based on this, the browser redirects to the success page or displays an error message.

At different stages there are different conditions for stopping the process - invalid tokens, empty accounts or shutting down the Internet - but the logic remains the same. And in this case, you can completely render the page on the server, but the difficulties with this will be discussed below.

For Google Pay, you need a few more intermediate steps.

Firstly, between choosing a payment method and tokenization there is an appeal to the API from Google - this is needed to check whether the device supports payments via Google Pay. After clicking on the “Pay” button, the Google Pay web interface appears, where the user logs in, selects one of the added cards, or enters details of the new card.

Secondly, there is another security circle from Google. The browser does not receive the details directly - the cryptogram comes to it, which, in turn, goes to the backend for tokenization. There she decrypts keys from Google, and then see step 3.

Naturally, each additional stage (even strictly following the documentation) is additional development and testing time. The more pleasant that the merchant does not have to do almost anything - it is easy to connect payments through Google Pay to any site where there is a Yandex.Cashy payment form. Details - on site Cashier .

An interesting story was also found in the frontend - it is about creative search, evidence and UX.

Google Pay button on the payment page

The Cashier’s payment page is completely collected on the server - it receives data from the backend, drives it through the template engine and gives the browser ready HTML, CSS and JavaScript code. So the page is drawn faster - when all data is ready, and all dynamic content works through JS on the client.

The difficulty is in determining whether the added means of payment are in the client’s Google account is possible only through the client library from Google. Therefore, the logic that draws the part of the page with the payment button needed to be implemented on the client. The technical solution was found after a brief search.

On the backend, you need to check if the store has included payment via Google Pay - if so, then in the template engine add a CDN link to the Google Pay library to the page and give the browser a sign that you need to download data using this payment method.

On the client, you need to check if there is a required sign - and if so, call the method of checking whether payments via Google Pay are supported on this device. If all is well, then we show the user one more button. As a result, the page is still rendered on the server, but now we are making a couple of additional requests to another service.

It just turned out that this service can sometimes not respond.

A whole month a single gap!

This story is about our UX-department - how they were looking for a way to render the Google Pay button, but not to interfere with the user to interact with the form.

The first thought is to hang the whole page and wait for a response from Google.

But if you wait for a response from Google, then there is no point in server rendering (the user still cannot interact with the page until we receive the data on the client), and we begin to depend on third-party services. If there is a problem with the Internet, Google is blocked or unavailable, the user will not be able to use the page, although nothing will prevent him from entering the card number.

Designers made a few more options, but for various reasons they did not fit, and the requirements for the models gradually changed.

Approach once

Approach two

As a result, there were three main requirements:

1. The user should be able to pay regardless of whether the third-party service responds and how long it will do. The service should not become slower.
2. Need scalability. When payment from Apple or Samsung is added, this should not affect the speed and ability to work with the fields of a bank card.
3. The solution should not have too much animation / dynamics. If the user begins to enter data, and at this time the Google Pay button loads and something changes, the user may not understand what happened and why.

On their basis, the final design of the payment form. He arranged for all the criteria - scalable, does not block the input of a bank card, and there is no extra animation when receiving bank card data.

And what about smartphones without NFC?

To pay via Google Pay in offline stores, NFC is still needed, without options here.

NFC is not needed online. All desktop browsers work fine with Google Pay. There are nuances with smartphones - Google has several requirements for a device with Google Pay. Here is a list of what is not allowed:

1. Use a phone with Android 4.4.3 or earlier;
2. Install Android version for developers;
3. Make root, unlock bootloader or install unofficial firmware;
4. Use Samsung MyKnox;
5. Use an unchecked Google device.

In other cases, payments via Google Pay on the Internet should work fine - but no one knows about all the exceptions, perhaps.

Harsh business conclusions, if you already use Yandex.Cash

To enable reception of payments via Google Pay, write to the manager in your account. After a while, the button will appear by itself, and you can spend the time of developers on something else.

Conversion will increase - according to Mediascope, 36.3% of users pay without contact. Yandex.Money's own research has shown that 43% of cardholders use them for contactless payment. In addition, among Android users, there are quite a few people with Chrome - they will not need to enter the 3-D Secure code.

Harsh business conclusions if you are not yet using Yandex.Cash

Urgently connect , why pull something?

Other stories about what is good at the Cashier
Ten people at 90 thousand sites: how not to go crazy
I'm tired of accepting payments through WebView. What should I do?
How we protect reviews, purchases and travel from scammers