Sometimes it is time to stop and take a fresh look at what you are doing. What if previous decisions once seemed right, and now they create problems? Take courage and start from scratch. In the meantime, I’ll tell you how QIWI made a commercially correct choice 8 years ago when launching a product, but in 2015 we had to redo a lot.

How it all began?

A long time ago, in the far-distant galaxy was 2008. At QIWI, they are thinking about providing online stores with a payment method from the QIWI e-wallet. The protocol that has already been used was intended for clients with an account on the provider side. For example, a client wants to replenish the mobile balance by $ 100 - please, $ 765 is also not a question. In the terminal or personal account, it is enough to indicate the contract number with the provider and pay. This protocol was historically called push.

If a customer buys in the iPhone 3G online store for $ 22,999, he cannot pay $ 20,000 or $ 25,000, he needs to transfer the store exactly $ 22,999, so he needed to develop a new protocol.

The main trump card of the company on the market were payment terminals, and in order to use them to the maximum, deferred payment had to be maintained. Obviously, the closest real-world analogy is billing. But how to notify and how to link the account with the user? Of course, we decided to use the phone number, because The company has already successfully used it as an identifier.

This is how the invoice handling protocol (Pull) appeared, when a customer chooses a product in a store, informs that he wants to pay it with QIWI. Next, enter the phone number, the store server bills by API, and the happy user goes to pay to the terminal, to qiwi.com or to the partners. As a result, the store receives an alert about the successful payment or cancellation of the account.

After the development of the API began to actively sell it. Shops billed and offered customers to go to the terminal or on qiwi.com. After a while, it became obvious that we needed a page that would beautifully explain to the user how convenient it is to pay the bill. They made it and called it a scary word “checkout”. At the same time, a system for filing applications for connecting and setting up a protocol was created - ishop.qiwi.com .

Evolutionary degradation

The initial logic of the payment page was simple: log in and pay with QIWI balance. Entering the phone number remained on the side of the store, because this was implied by the billing protocol.

Even then, we stepped on the rake of waiting for reasonableness, deciding that the protocol is simple and straightforward.

It turned out that if something could go wrong - it will go there, but more on that later. Then came the linked cards, mobile commerce, linked Webmoney, a trial launch of microcredit. All these innovations gradually changed the bill payment page, but without regard for the overall user experience. For example, mobile commerce did not require a password entry, so they added a page for pre-selecting a payment method, which complicated payment from the balance. In addition to the implementation of different payment methods, there were changes due to internal requirements, for example, stricter password change rules.

Everything was done logically and correctly from a business point of view, but let's look at the payment scenario for the user by 2014. Suppose you are a customer who used QIWI once, but six months have passed. During this time, the mobile operator could give the number to another person, so the wallet was marked as inactive. You deposit money through the terminal, come to the store, choose payment through QIWI, enter the phone number and go to the bill payment page.

The first page opens with a pre-selection of the payment method, then the registration page, payment confirmation with the choice of payment method and SMS confirmation of the operation will follow.

As a result, up to 8 steps with hellish logic for a new user or user who has forgotten the password. Cherry was a payment by credit card only after being tied to a wallet.

Since its inception, QIWI reminds more of a startup than a bank, so the product has evolved during the implementation of business projects, for example, integration with Megaphone, and priority was given to speed of implementation. The approach is very effective, but sometimes it requires a general cleaning.

MVP on crutches

To make the payment process more convenient, we made a plan with a complete rework of the entire payment page. But it became clear that this is a long process. Therefore, in parallel with the work on the UX / UI, we chose the most important changes for the current product.

First, we decided to make authorization by one SMS instead of a password, that is, OTP - one time password.

The fraudsters quickly learned how to deceive users by fishing for the desired text message, so OTP was included only for trusted partners with a large turnover and without the option of withdrawing funds. Also for the scenario with OTP, the registration of new users has been greatly simplified, requiring only SMS entry and acceptance of the offer.

We also reduced the extra pages and added a bit of mind. Based on the amount of the invoice, the service began to determine which of the payment methods would be convenient for the user: if he had a balance in the wallet, then only one click remained before payment. At the same time, together with the team responsible for payment by cards, they made a payment by entering the card details on the page without prior linking.

For 3 months, all changes were implemented and the turnover went up with the conversion. However, the payment page was still included in one application with the site, so it was impossible to calculate the statistics correctly, and the technological debt went off scale. It was also difficult to guarantee the stability of work in the moments of shares with partners and synchronize changes in products. It's time to take on the upgrade service.

Brave new world, or SPA zone

In 2015, QIWI began to switch to the microservice architecture. The best candidate for the restructuring was the payment page. It was decided to create a separate Java service that implements the REST API and the web application. Well, that indexing by search engines was not required.

The experience of creating web applications (SPA - single page application) on React JS in the company did not yet exist. It took time to hire a front-end developer, as well as learn new approaches: exploring the tools, choosing the development stack, setting up continuous builds in TeamCity and the internal npm repository, choosing a testing methodology.

By the time the development began, the UX prototype was tested, which allowed us to simplify the design of the API. Of course, the team had to rake up a large layer of heritage, sometimes substituting crutches, since old architecture did not imply such barbarism.

For understanding React JS

At the time they started developing solutions like redux, they were not as popular as they are now. Therefore, we used the observable-state approach. Initially, we used baobab, but at that time he had a poorly developed Computed state, and we switched to our own similar solution, since Dependency injection was required as an adhesive for the components. The diagram shows the separation of application components into layers. It differs from the usual flux or redux operation patterns by effects — actions on data loading and state modifications that are performed during component initialization (componentDidMount). There are also computed states (Computed) and cached data loaders (Loader).

Analyze it

For six months we have done and prepared for launch the first microservice in the company. But not everything went smoothly. December is not the best time for running new solutions that affect payment. It's funny that partners with a small turnover were the first to receive a new product. We launched the product, gradually controlling fluctuations in turnover, conversions and errors.

For December, we debugged the receipt of basic statistics on active partners, users, general conversion, corrected key problems, but on January holidays almost everyone was returned to the old application.

In January, a mass launch began that lasted for 3 months, since unexpected errors constantly occurred. For example, some of the partners did POST redirect to the page, although only GET is described in the protocol. There was a major partner who opened the page in the Adobe Air browser, where the standards are very bad.

And of course, partners who used old protocols or simply ignored all the documentation and did not open the login pages, but something that seemed appropriate to them. Therefore, in the new version of the product, we focused on analytics, namely on the search for problem indicators. They helped us make many unexpected discoveries. When the product was separated, they began to build up funnels for each payment method in combination with the type of provider and the currency for which it works. The problems that were lost in the general graph of turnover and conversion came to the surface.

We were surprised to see that many, even large partners, do not send a client to the payment page, but only say that the invoice has been made and you can pay it somewhere in QIWI. If you use the pull-protocol, make sure that you redirect to bill.qiwi.com, otherwise you complicate your customers' lives and lose up to 30% conversion.

We learned to support these and other problems due to non-standard behavior in a new product.

Most of the launch were welcome in AliExpress. There have long been expected mobile layout on the payment page. Interestingly, the number of users of the mobile version has increased significantly after the appearance of a convenient UI and reached 40% or more. On promo days on AliExpress, the share of users with mobile interfaces reached 80%.

Turnover on the maps in general was able to raise more than 2 times the succession of testing hypotheses! Much of this has become possible because project approach with maximum focus on the launch of the project was replaced by a phased development of a single product by one team. I am glad that after launching active development continues, and soon we will share good news.

Personal, programmer

I have been working in QIWI for 5 years, I came as a programmer for Flex-AS3. The team developed applications for social networks. Then there were node.js and Angular JS and a restaurant startup. Transition to project management as an analyst / project manager with the integration and launch of eBay-QIWI, the closure of the old ishopnew.qiwi.ru and the transition to ishop.qiwi.com, as well as the launch of a new bill payment page. Now I am responsible for the development of b2b products for e-commerce: bill payment pages, ishop.qiwi.com and the internal monitoring system of providers. It turned out to collect an interesting experience in a small company and in big business from several sides: development, project management, and product development business.

I like the transition to agile and small grocery teams now. True, I can say that not everyone fits this style, because on each member of the team there is a greater responsibility, and for example, the Timlides, on the contrary, should contribute to greater autonomy of the developers, who are divided into teams. However, this allows a large company in many ways to become as flexible as a small startup, and the whole team to get a unique experience.

There are not so many companies that create and develop products themselves, and at the same time really simplify the life of their users. QIWI is one of them. Launching your own product changes the world view, which is why the company encourages this, but as we know, start-up units grow to a real business. QIWI offers to develop a product that is used by thousands, tens or hundreds of thousands of users - this is an opportunity for growth and an inspiring experience.

Now we are preparing for a significant update of the QIWI partner connection site - ishop.qiwi.com. While he, to put it mildly, is not perfect, but we are going to significantly change the approach to working with partners, and for this, a new architecture with an open API is extremely important.

Therefore, I invite Senior Java with the experience of writing the REST API to join our team and turn the world around for thousands of our partners this year.

In general, we in QIWI will always welcome Java and JS (React JS) developers, since There are a lot of interesting directions of development. We also have a quiet hour and regular hackathons. Join in!