How to legally "open" QIWI Wallet and pump it in full
Recently, Visa QIWI Wallet users have access to new API methods. Under the cut: what is the API, why we opened it and why you should start using it now.
Formally, the history of our API began in April of this year, although some of its member methods were available long before that.
The QIWI Wallet mass user service is gradually moving to microservice architecture, so components inside our system interact with each other through some kind of API. Any user can go to the site, open the debugger and see what requests the browser sends to the server. The minimum programming skills are enough to pull out the queries sent and use them in your own solutions to bypass the site.
')
There were quite a few people who wanted to cheat like this. These are enthusiastic students who are interested in digging into the details of the Wallet, and professional developers who want to integrate certain functions of the QIWI Wallet site into their solutions. As a result, in parallel with the development of the site, a whole ecosystem of third-party solutions began to develop in a “gray” mode, not legalized in the user agreement and not supported by our support.
Here are just the scripts built on the results of independent research of the site, working for users is unstable. Developers use different methods of extracting information, including outdated methods that create additional load on our servers.
In order to streamline the uploading of data from the site, we decided to legalize it, as we did in Citibank, Wargaming and Vkontakte. We have described the most modern and stable of the existing ways of obtaining information, creating the first version of the user API.
With the advent of developer documentation, users no longer need to parse our site in pieces, risking to stumble upon old protocols. By attendance of the documentation section, we tracked how much the API is in demand. We also posted an email address for feedback and questions and monitored publications on the topic in social networks and forums. At that time, we were not faced with the task of somehow promoting the API - we wanted to restore order and offer third-party developers a free, secure, proven access method.
Publication of API documentation itself did not affect the work of third-party tools for accessing Wallet functions. We did not plan to regulate "samostroy", but watched the situation, because the solutions were built by developers at their own risk and risk based on undocumented features of the service. And as long as they do not affect the data of our users, we do not fight with them at all, but we try to get in touch with their creators and recommend switching to using the documented API.
Since the requests went through site parsing, it is obvious that solutions using methods that go beyond the API will work as long as the corresponding schemes work on the site. But we hope that after the appearance of a better way, the undocumented decisions will gradually die off.
Unfortunately, at the time of creating the first version of the API, we did not yet have a separate authentication system. Therefore, at that stage we used the authentication scheme from our site (CAS), it was disassembled into separate teams and published on developer.qiwi.com .
Authentication has become a key issue in the first API. If, from the site’s point of view, the mechanism was correct (this is how the authentication is organized on most web pages, based on the principle of two tokens with different lifetime), then the user was quite difficult to go through the procedure. This method was not originally focused on users, but served the internal tasks of our site. As a result, various difficulties arose, for example, the captcha “prove that you are not a robot” popped up, which was a surprise for users, since the API implies access using automatic systems.
Although we did not publicize the publication of the open API, several articles appeared on the network, including those with negative reviews. We received over a hundred letters to the feedback address api_help@qiwi.com , the meaning of which was that the API itself was good, but authentication was no good. Not all users understood why connecting to a financial service requires such an intricate procedure, while with Instagram or Vkontakte everything is much easier. We explained that the difficulties were due to the financial component, because the method used (both in site authentication and API) should not jeopardize customer accounts.
Analyzing the feedback, we saw that the API is in demand, and the criticism is mainly aimed at the authentication system, and decided to develop the API further.
The development of new methods within the framework of the API was entrusted to a team of experts who make the backend for the site and the QIWI Wallet mobile application. The API is their core competency; it is this team that translates the main site into microservice architecture. And the API here serves for the interaction of the main site and individual entities through requests that we pass to our users.
To refine the existing API and add new methods to it, we carefully analyzed user feedback.
Although there are a lot of enthusiastic enthusiasts among our clients who are inclined to try something new, the main part of API users is professional developers who integrate QIWI Wallet into their business processes (and this is not online shopping - we have a separate API for legal entities ). Basically, it’s about optimizing the Wallet for your own needs: setting up notifications, automating payment for services and exchanging digital goods between users, as well as other tasks not related to the usual e-commerce.
Based on the reviews, we proposed a new user authentication through the API, added new functions for interacting with the Wallet. In the first version, we had a balance request, payment history and transfer transfer. Now they have been supplemented by a request for a user profile, payment for cellular communication, transfers to banks and to cards using card, account and contract numbers instead of full details.
To build an API-oriented authentication system, we used the RFC 6749 standard using the open OAuth 2.0 protocol. In order for the authentication to meet the requirements of the financial service, we provided two-factor access - by password to the Wallet and SMS code. To complete the procedure, the user needs to issue a token valid forone month 180 days (the issue is confirmed by an SMS message). At the request of users in the new version of OAuth 2.0, we also opened the choice of access rights for the token. For example, if you want to request a balance or get a payment history, the token is given read only rights. There are four groups of access rights available:
The function turned out to be very popular, less than half of tokens are issued with full rights (making payments), many only need to receive information.
One of the new features that were born within our team, and not from the wishes of customers - request a user profile. It allows you to receive various information about the Wallet: the date of registration, the associated email address, the level of identification of the Wallet. The latter is especially important for financial services, since the level of identification determines the limits on operations for the wallet. Previously, this information could be found in the Wallet settings on the qiwi.com website; now it is also available through the API.
Note that the personal data of the user through the profile request is not available - this is a security requirement.
Following the wishes of users, we added to the API the ability to request a fee when conducting transactions on any of the available service providers. This method is open and does not require authentication.
Another innovation, initiated by our users, is a tool for automating cellular payments, for example, for courier phones.
In fact, the method consists of two stages:
By analogy with the payment of cellular communication, this group of API methods allows you to automate transfers to bank cards of VISA, MasterCard systems and the national payment system MIR in Russia and the CIS. The transfer is carried out according to the card number, which determines the payment system.
Bank transfer is a separate method used to send money to some banks with which we have implemented an online protocol for instant money transfers. Unlike conventional money transfers by bank details, for these banks you can use a greater number of customer identifiers (card number, agreement, account, etc.).
Until recently, API access was formally denied. Everything that was done using the API was done at your own peril and risk. If a user broke the site, pulled out some commands from him, conducted operations with the wallet, and he lost money, he was fully responsible for the consequences of his actions. Technical support was not involved in solving such problems.
To prevent such situations from happening again, we made the appropriate changes to the user agreement. Now API has official status on a par with the site and the mobile application.
The listed data access methods are already working, and the documentation on them is published on the developer.qiwi.com website.
Internal testing has been completed, and, having published the API, we have moved to the second stage - testing the functionality of the “user + documentation + API” bundle. This stage should answer questions about how clear the documentation is, whether any additional explanations are needed, etc. Therefore, we suggest that users send feedback to our address: api_help@qiwi.com .
In the near future, we plan to expand the API's capabilities by providing third-party services with methods for registering new users and authenticating existing users in the system, as well as conducting financial transactions on their behalf. This is a slightly different model of interaction between us, the user and a third party - a third-party service.
If you are interested in the details of developing a new version of the API, write and ask questions in the comments - we will try to answer them in our next publications.
To interest developers in using the new API, we are conducting the All-Russian QIWI API Contest. This is the first competition within the QIWI Open Platform, aimed at promoting the company's API.
To participate in the contest, you need to create Mobile First solutions - chat bots, mobile applications and web-products using the QIWI Wallet API. Our experts will select the most developed solutions and invite up to 15 participants to the final of the competition, which will be held in Moscow on September 23.
Contestants from other cities can participate remotely. Registration of projects is open and will run until September 15. You can apply for participation in the QIWI API Contest via Timepad or send it to apimarket@qiwi.com . For all questions we created a special chat in Telegram .
08.25.2017 update:
API history
Formally, the history of our API began in April of this year, although some of its member methods were available long before that.
The QIWI Wallet mass user service is gradually moving to microservice architecture, so components inside our system interact with each other through some kind of API. Any user can go to the site, open the debugger and see what requests the browser sends to the server. The minimum programming skills are enough to pull out the queries sent and use them in your own solutions to bypass the site.
')
There were quite a few people who wanted to cheat like this. These are enthusiastic students who are interested in digging into the details of the Wallet, and professional developers who want to integrate certain functions of the QIWI Wallet site into their solutions. As a result, in parallel with the development of the site, a whole ecosystem of third-party solutions began to develop in a “gray” mode, not legalized in the user agreement and not supported by our support.
Here are just the scripts built on the results of independent research of the site, working for users is unstable. Developers use different methods of extracting information, including outdated methods that create additional load on our servers.
In order to streamline the uploading of data from the site, we decided to legalize it, as we did in Citibank, Wargaming and Vkontakte. We have described the most modern and stable of the existing ways of obtaining information, creating the first version of the user API.
With the advent of developer documentation, users no longer need to parse our site in pieces, risking to stumble upon old protocols. By attendance of the documentation section, we tracked how much the API is in demand. We also posted an email address for feedback and questions and monitored publications on the topic in social networks and forums. At that time, we were not faced with the task of somehow promoting the API - we wanted to restore order and offer third-party developers a free, secure, proven access method.
Publication of API documentation itself did not affect the work of third-party tools for accessing Wallet functions. We did not plan to regulate "samostroy", but watched the situation, because the solutions were built by developers at their own risk and risk based on undocumented features of the service. And as long as they do not affect the data of our users, we do not fight with them at all, but we try to get in touch with their creators and recommend switching to using the documented API.
Since the requests went through site parsing, it is obvious that solutions using methods that go beyond the API will work as long as the corresponding schemes work on the site. But we hope that after the appearance of a better way, the undocumented decisions will gradually die off.
Problems of the first version
Unfortunately, at the time of creating the first version of the API, we did not yet have a separate authentication system. Therefore, at that stage we used the authentication scheme from our site (CAS), it was disassembled into separate teams and published on developer.qiwi.com .
Authentication has become a key issue in the first API. If, from the site’s point of view, the mechanism was correct (this is how the authentication is organized on most web pages, based on the principle of two tokens with different lifetime), then the user was quite difficult to go through the procedure. This method was not originally focused on users, but served the internal tasks of our site. As a result, various difficulties arose, for example, the captcha “prove that you are not a robot” popped up, which was a surprise for users, since the API implies access using automatic systems.
Although we did not publicize the publication of the open API, several articles appeared on the network, including those with negative reviews. We received over a hundred letters to the feedback address api_help@qiwi.com , the meaning of which was that the API itself was good, but authentication was no good. Not all users understood why connecting to a financial service requires such an intricate procedure, while with Instagram or Vkontakte everything is much easier. We explained that the difficulties were due to the financial component, because the method used (both in site authentication and API) should not jeopardize customer accounts.
Analyzing the feedback, we saw that the API is in demand, and the criticism is mainly aimed at the authentication system, and decided to develop the API further.
Updated API
The development of new methods within the framework of the API was entrusted to a team of experts who make the backend for the site and the QIWI Wallet mobile application. The API is their core competency; it is this team that translates the main site into microservice architecture. And the API here serves for the interaction of the main site and individual entities through requests that we pass to our users.
To refine the existing API and add new methods to it, we carefully analyzed user feedback.
Although there are a lot of enthusiastic enthusiasts among our clients who are inclined to try something new, the main part of API users is professional developers who integrate QIWI Wallet into their business processes (and this is not online shopping - we have a separate API for legal entities ). Basically, it’s about optimizing the Wallet for your own needs: setting up notifications, automating payment for services and exchanging digital goods between users, as well as other tasks not related to the usual e-commerce.
Based on the reviews, we proposed a new user authentication through the API, added new functions for interacting with the Wallet. In the first version, we had a balance request, payment history and transfer transfer. Now they have been supplemented by a request for a user profile, payment for cellular communication, transfers to banks and to cards using card, account and contract numbers instead of full details.
New authentication
To build an API-oriented authentication system, we used the RFC 6749 standard using the open OAuth 2.0 protocol. In order for the authentication to meet the requirements of the financial service, we provided two-factor access - by password to the Wallet and SMS code. To complete the procedure, the user needs to issue a token valid for
- access to user profile information;
- access to the Wallet balance;
- access to payment history;
- full access to payments.
The function turned out to be very popular, less than half of tokens are issued with full rights (making payments), many only need to receive information.
User Profile
One of the new features that were born within our team, and not from the wishes of customers - request a user profile. It allows you to receive various information about the Wallet: the date of registration, the associated email address, the level of identification of the Wallet. The latter is especially important for financial services, since the level of identification determines the limits on operations for the wallet. Previously, this information could be found in the Wallet settings on the qiwi.com website; now it is also available through the API.
Note that the personal data of the user through the profile request is not available - this is a security requirement.
Commission rates
Following the wishes of users, we added to the API the ability to request a fee when conducting transactions on any of the available service providers. This method is open and does not require authentication.
Cellular payment
Another innovation, initiated by our users, is a tool for automating cellular payments, for example, for courier phones.
In fact, the method consists of two stages:
- automatic identification of the operator by phone number and service provider ID in the system (works even for numbers that were transferred from one operator to another (MNP);
- transfer of money to the operator’s account.
Transfers to banks and bank cards
By analogy with the payment of cellular communication, this group of API methods allows you to automate transfers to bank cards of VISA, MasterCard systems and the national payment system MIR in Russia and the CIS. The transfer is carried out according to the card number, which determines the payment system.
Bank transfer is a separate method used to send money to some banks with which we have implemented an online protocol for instant money transfers. Unlike conventional money transfers by bank details, for these banks you can use a greater number of customer identifiers (card number, agreement, account, etc.).
The legal side of the issue
Until recently, API access was formally denied. Everything that was done using the API was done at your own peril and risk. If a user broke the site, pulled out some commands from him, conducted operations with the wallet, and he lost money, he was fully responsible for the consequences of his actions. Technical support was not involved in solving such problems.
To prevent such situations from happening again, we made the appropriate changes to the user agreement. Now API has official status on a par with the site and the mobile application.
What will happen next?
The listed data access methods are already working, and the documentation on them is published on the developer.qiwi.com website.
Internal testing has been completed, and, having published the API, we have moved to the second stage - testing the functionality of the “user + documentation + API” bundle. This stage should answer questions about how clear the documentation is, whether any additional explanations are needed, etc. Therefore, we suggest that users send feedback to our address: api_help@qiwi.com .
In the near future, we plan to expand the API's capabilities by providing third-party services with methods for registering new users and authenticating existing users in the system, as well as conducting financial transactions on their behalf. This is a slightly different model of interaction between us, the user and a third party - a third-party service.
If you are interested in the details of developing a new version of the API, write and ask questions in the comments - we will try to answer them in our next publications.
Attention! Competition
To interest developers in using the new API, we are conducting the All-Russian QIWI API Contest. This is the first competition within the QIWI Open Platform, aimed at promoting the company's API.
To participate in the contest, you need to create Mobile First solutions - chat bots, mobile applications and web-products using the QIWI Wallet API. Our experts will select the most developed solutions and invite up to 15 participants to the final of the competition, which will be held in Moscow on September 23.
Contestants from other cities can participate remotely. Registration of projects is open and will run until September 15. You can apply for participation in the QIWI API Contest via Timepad or send it to apimarket@qiwi.com . For all questions we created a special chat in Telegram .
08.25.2017 update:
- now tokens live not 30, but 180 days;
- launched the QIWI API Contest website.
Source: https://habr.com/ru/post/335742/
All Articles