QIWI-terminals. How to get the most out of simple technologies

At the beginning of 2017, we, the software development team for QIWI Terminals, collected the wishes of the company's divisions - we learned what global tasks our colleagues would like to solve with our help, to make life easier.

Most of all, I was pleased with the request of the customer service working with calls and the claim from payers:

“There is a problem: the client makes a payment at the terminal, but it still doesn’t get to the processing - either the terminal could hang up, or the Internet, working via a gsm modem, has fallen off. And it turns out that the client has a check, but there is no payment in the system. It would be good in such cases to learn how to deliver payments to QIWI.
')
There is also a group of anxious customers who immediately after making a payment, dial the number of the call center in order to make sure that everything is fine with it. It would be great to cut the cost of such calls. ”

So we had a complex task: learn how to create a payment in case of communication failure with the terminal and reduce the number of incoming calls from customers by inventing a self-service tool for checking the status of the payment. Case is clear. Began to look for a solution that is convenient for the client and without security risks.

The customer, according to tradition, offered his option - to type on the check a sequence of characters that the payer could tell the operator, and he, in turn, will understand whether it is our payment or not, filter the fraud or carry out the operation manually.

The concept of the idea was clear, but unrealizable, so we went a little further: we decided to embed the payment data into a QR code, print it on the check, and to be faithful, duplicate it on the QIWI Terminal screen. Scanning the QR code with the camera of his device, the client can find out the status of the operation. And in case of failure of the payment in QIWI, the system automatically creates it. Thus, the client will not only find out whether the money has come, but also conducts it independently, regardless of the state of the terminal.

At first glance, the decision was obvious: take an existing request with a payment, wrap it in a QR code, write a web page with information about the transaction and microservice that proxies requests between the terminal, processing and the web. It was assumed that the project will work on the existing methods of authentication of the terminal and use the existing methods of payment in processing.

The idea came right away, revealing the creative potential of the team. We started gushing and throwing additional options up to placing the logo, slogan and even advertising in the QR code, in addition to the payment data:


The project for a couple of sprints, no more. It was not there.

First frustration

We took an existing payment and formed a QR code on it:


As a result, even the last iPhone7 at that time could not count it. On the check, the QR code, consisting only of the payment and signature data, could barely fit on a half A4 sheet. The payment request line was too long. This was the first pechalka.

It was necessary to solve two main tasks:

• reduce the number of characters in the payment request, i.e. come up with a solution where we can get away from the existing xml request to a more compact one;
• select the encryption algorithm and key length, which will ensure high cryptographic strength and reliability with a smaller signature size.

There was one criterion for evaluating the optimal number of characters for a QR code - it should be read by the cameras of most mobile phones.

For a couple of working meetings, a solution was found after all:

• instead of an xml request, we decided to use a get request with payment parameters and delimiters between them;
• built a signature on the elliptic curves to shorten the length.

The advantage of using the get-request was that the mobile phone cameras or special programs, seeing the link in the QR code, immediately open it in the browser, which allowed making a payment in one action. To reduce the size of the get request, we had to replace the name of the parameters with delimiters.

As a result of a set of actions, the request for payment was reduced from approximately 1,100 to 200 characters. Plus, I had to apply the lowest level of QR code error correction - L.

For implementation it was required to carry out the development of components in the system:

• create a new api for making payments via a QR code;
• introduce a new mechanism for working with cryptographic keys between the terminal and processing;
• implement a microservice on which the functionality of proxying queries, checking the integrity of the data, as well as the function of blocking suspicious requests and collecting statistics of operations will hang;
• develop a web page to display payment information;
• develop a system of limits and checks for a new payment channel.

To the existing work scheme:



Planned to add an alternative:



In the course of the project, there seemed to be small, but requiring to solve problems, which in fact took a lot of time, postponing the launch date.

UX-research, or the work came from no waiting

I wanted to do everything, like people do, so for the implementation of the project UX-specialists were attracted to solve the questions:

• in which part of the QIWI Terminal screen to place the QR code and how to explain its usefulness to the client?
• Where to place the QR code on the check and how to cram similar explanations?
• How to make a layout of a web page with payment status, so that it can be understood by the company's guidelines?

It is obvious that for the advanced part of clients no further clarification on the QR code is required, it is enough for them to indicate the result. But we wanted to cover the part of our clients for whom the QR code is a magic abbreviation or just a “black square”. It is they who, in fact, terminate the call center line.

To make it beautiful and understandable, an interview was conducted within the focus group that interests us with unexpected results ...

Brevity - Relatives Savings

It turned out terrible - the audience we needed did not always understand the meaning of the word “Scan” and its derivatives. Therefore, the initial wording “Scan and find out the status” had to be abandoned. The solution was the technical ability to send a photo of a QR-code by e-mail. And this, too, had to be said briefly and clearly, because the check tape is a consumable material of the owners of the terminals and our concern for the business of these people is its economy. As a result, the check now looks like this:


As for the display of the QR code on the terminal screen, it was placed on the final page of the payment - the most recent in the payment scenario. It is shown at the time of printing the receipt and in fact is an electronic duplicate of the printed QR code.

Email is omnipresent

In connection with the advent of a new channel for processing a QR code in the form of an e-mail, it became necessary to develop mechanics with the function of recognizing QR codes embedded in a letter and forming a response with the payment status.

The recognition function of QR codes was rendered to microservice. During the initial implementation, the percentage of recognitions was about 65% in the presented sample of photos. We tried to play with discoloration and contrast enhancement - this gave about + 20% successful recognitions.

The cherry on the cake in the task of recognizing a photo of a QR code was the introduction of “natural intelligence” for hard, poorly recognizable cases - the creation of applications and their processing were carried out in manual mode:

Technical not trivia

The main developments on this project, of course, concerned microservice itself and terminal software.

In QIWI, they are actively switching to microservice architecture in order not to touch the massive engine. Microservice allows you to quickly make changes to projects, conduct tests and release releases. Therefore, in a couple of months we wrote our own. On it, we hung all the major new developments that could only be made:

• proxying requests by parsing and analyzing incoming get requests, converting them into xml for processing,
• functionality to limit incoming requests from terminals,
• QR code recognition functionality
• collecting statistics for further analysis.

In addition to implementing a new mechanism for working with cryptographic keys, terminal improvements touched on the issue of applying a new printing technology for checks.

The functionality for their formation was moved from the main program kernel to the plugin. Now we could implement changes to the check promptly, without touching upon the operability of the terminal as a whole. The task of printing a QR code, which, at first glance, seems simple enough and comes down to printing a picture on a check, in fact, is not.

This is because our agent terminal owners are online with about 20 models of various printers, and we print about 40 types of checks. When they started to implement, they got out a lot of nuances: then the lines and the location of objects in the check pattern began to float when adding a picture, then some teams were sensitive to the location, and then the line break turned into a tabulation.

We started testing, realized the need for a compromise - we had to exclude some printer models, because when testing all configurations, an immense number of cases came out.

For the tests we decided to choose 6 main models, which covered 91% of the agency network. And, of course, at the time of the sampling tests in a combat environment, it turned out that just on ancient printers, which covered about 5% of the agency network, problems with printing checks were revealed. The models were so old that even in the market they were no longer to be bought. I had to look for partners. Now the project covers 96% of the network. Already a little closer to the ideal :)

Do not check one

In parallel with the placement of information about the QR code on the check and the final page of the payment, another task was tightened - to bring this page to a universal form for all terminal projects:

“In terms of the payment completion pages in QIWI Terminals, everything was quite archaic: advertising, banners and sending an electronic receipt. The guys made one of five pages, universal for all payments. ” - Lead programmer of the team.

Now this universal page is used in different interpretations, without getting out of the rule of building a script, closing the karmic debt of the development team.

Thus, the task was solved a decade ago, to which every time did not reach the hands. There were several such long-running tasks.

“Where is the money, Zin?” Or what’s the bottom line

The project, designed for a couple of sprints, took six months, affecting the resources of 10 employees and the edge of the outsourcing agency.

As a result, having implemented the project on 85% of the terminal network, we surprised ourselves and the customer - customer service. On the third day of the QR-code, the colleagues thought that a system error had crept in on them - statistics on the number of calls to the call-center with the question “Where is my payment?” Has already dropped by 20%. Clients began to scan the QR code and send a photo of the checks by e-mail, finding out the status and making the payment on their own. And so the second month. I must say that customers began to understand what a “black square” is and how it is useful.

The project with a QR code was liked by everyone who was told about it - it was a synergy of interests: on the one hand, they simplified the client’s life, on the other hand, they solved a non-standard technical problem. Check the status of the payment and conduct it in processing "by piece of paper" by simply scanning the QR code for QIWI - something new. To take the well-known and simple technologies from which to make a useful project was great. In general, the project not only pumped skills, but also improved communication within the team. And this is almost the main plus sign in karma.