Sorry, we are updating the protocol
Back in 2011, we were asked why enter a phone number for billing on the side of a partner connected to QIWI? We have long wanted to facilitate the integration of the API, but earlier it was quite difficult to do this. What has changed in 2016? Now we will tell, and also we will experiment with Habrovsky R & D voting.
If to simplify, in work on any project in the company three groups participate:
Each division had its own subgroups with queues and priorities. The task for a serious revision of the site involved a legion of colleagues:
')
With this approach, projects were quickly launched that were prioritized for the tops: they were allocated a separate project team that ran even super-complex projects out of priorities and queues in the shortest possible time. However, all other product tasks could be stuck in the implementation queue. The development of already launched products suffered the most.
Now in QIWI teams are formed for specific products. At the same time, for example, a Java developer from the product team, if required, may make changes to payment processing, which will be verified and accepted. Previously, this should have been done only by the processing developers, since Web developers switched to other projects in their task queue. The new approach makes the team more flexible, and the time to implement the new functionality is significantly reduced. Let's see how we decide to change.
Alteration of the main protocol is a crucial step, but the obligatory entry of a phone number on the partner’s side complicated integration and payment. We explored two options for development:
1. Now our server REST protocol requires you to specify the phone number for billing. Considered the option of refinement for billing an arbitrary identifier or email.
Pros:
Minuses:
2. The company had an http protocol with number input on the QIWI side. But it was not verified in any way that the bill is billed by the partner. This protocol was ideal for collecting donations, but for large partners it could not be used in this form. The solution was to add a signature or hash and their subsequent verification when redirecting to the bill payment page.
Pros:
Minuses:
After a brief discussion, the second option was chosen. Initially, the security service and IT-division preferred the formation of a signature based on the public and private keys. However, recalling the experience of integration even with large partners and the number of emerging issues and problems when replacing certificates, we decided that we would stop at checking the sha512 hash.
There was a question, what parameters to hash? The easiest option is to sort everything alphabetically, add a secret key and take a hash. After the analysis, it became clear that there could be problems with comments and encodings, so they reduced the list to the minimum necessary number of parameters.
The question remained how to determine the secret key. For basic authorization, the REST protocol uses a pair of API ID and API Password, which allows you to flexibly configure checks for a partner. For one site, you can create multiple authorization pairs and use them on different servers and versions of the site.
In the end, came to this algorithm:
An example implementation in PHP.
I propose, as an experiment, to decide together how to develop the protocol. We have not solved several technical issues and suggest you to think with us how to develop the protocol. For this, a vote has been added at the end of the article.
The main problem remains the lifetime parameter, which is responsible for the lifetime of the account. In the existing protocol, it was transmitted in minutes, and the bill was issued immediately after the redirection. In the new - the invoice can be issued much later, especially if the link was sent by email. Therefore, most likely, you need to add a new parameter with an absolute date. For example, in ISO 8601 format (2016-09-12T00: 00: 00), which is used in REST. But do they need seconds there? And ask whether to encode ':' in '% 3A', or replace it with '-', since many still pass the success_url without url coding and knock on support with questions. Most likely, the new parameter should also be included in the calculated signature.
The updated protocol is difficult, but allows you to make mass mailings. The main problem is the unique transaction id that will need to be generated when creating the link. For mass mailings with the purchase of a particular item, this may be difficult. The solution would be a set of purchase id and user account in the store, but then the user can buy something only once. The problem could be solved by making new parameters and removing the restriction on uniqueness. True, there are doubts that this is required by the market. Let's vote?
The new protocol is already ready for connecting partners, but so far it is activated only through the support service. If you want to take part in testing, write to cms@qiwi.ru or contact support.
You can estimate the current status of the payment page here . Happy programmer!
PS I invite a Java developer with good experience in implementing the REST API to join our team in launching the new ishop.qiwi.com and qualitatively turn the world around for thousands of our partners this year.
Alignment, pain and tears of large companies
If to simplify, in work on any project in the company three groups participate:
- Customers Responsible for the business idea of the project, financial evaluation, sales;
- Project managers. They are responsible for the technical implementation, determine which groups it will affect, control the general terms and the launch of the project;
- The developers. Implement and run the project.
Each division had its own subgroups with queues and priorities. The task for a serious revision of the site involved a legion of colleagues:
')
- Payment processing:
- Java developers responsible for payments, large partner APIs and standard external APIs
- Oracle developers responsible for database design and stored procedures;
- Web development:
- Java back-end + web developers API,
- JavaScript developers, especially for the SPA,
- Maker-ups;
- Q & A giving the go-ahead to the final product release.
With this approach, projects were quickly launched that were prioritized for the tops: they were allocated a separate project team that ran even super-complex projects out of priorities and queues in the shortest possible time. However, all other product tasks could be stuck in the implementation queue. The development of already launched products suffered the most.
Now in QIWI teams are formed for specific products. At the same time, for example, a Java developer from the product team, if required, may make changes to payment processing, which will be verified and accepted. Previously, this should have been done only by the processing developers, since Web developers switched to other projects in their task queue. The new approach makes the team more flexible, and the time to implement the new functionality is significantly reduced. Let's see how we decide to change.
Eight years later we decided
Alteration of the main protocol is a crucial step, but the obligatory entry of a phone number on the partner’s side complicated integration and payment. We explored two options for development:
1. Now our server REST protocol requires you to specify the phone number for billing. Considered the option of refinement for billing an arbitrary identifier or email.
Pros:
- A flexible approach, convenient for potential updates from existing partners,
- Maximum protection, because The protocol assumes only inter-server communication.
Minuses:
- Complicated integration for new partners, because you need to invoice before forwarding to the payment page,
- It is very difficult to make mass services with notification of bills,
- It requires a significant rework of the architecture of accounts in payment processing.
2. The company had an http protocol with number input on the QIWI side. But it was not verified in any way that the bill is billed by the partner. This protocol was ideal for collecting donations, but for large partners it could not be used in this form. The solution was to add a signature or hash and their subsequent verification when redirecting to the bill payment page.
Pros:
- Simple implementation for new partners,
- Low development costs by the team.
Minuses:
- There may appear "gifted" partners who will store the secret key and calculate the signature on the client.
After a brief discussion, the second option was chosen. Initially, the security service and IT-division preferred the formation of a signature based on the public and private keys. However, recalling the experience of integration even with large partners and the number of emerging issues and problems when replacing certificates, we decided that we would stop at checking the sha512 hash.
There was a question, what parameters to hash? The easiest option is to sort everything alphabetically, add a secret key and take a hash. After the analysis, it became clear that there could be problems with comments and encodings, so they reduced the list to the minimum necessary number of parameters.
The question remained how to determine the secret key. For basic authorization, the REST protocol uses a pair of API ID and API Password, which allows you to flexibly configure checks for a partner. For one site, you can create multiple authorization pairs and use them on different servers and versions of the site.
Algorithm and Example
In the end, came to this algorithm:
- We form an array of parameters:
- api_id - id to determine the secret key,
- currency - currency
- from - provider id
- summ - the amount
- to (if available) - phone number,
- txn_id - unique transaction ID on the provider side;
- Add to the array the secret key associated with api_id;
- We combine all parameter values into a string using the delimiter | between parameters;
- Calculate the sha512 hash;
- Add the string parameter signature in the request in the hexadecimal form in lower case.
An example implementation in PHP.
// ID , API_ID, API url: https://ishop.qiwi.com/options/rest.action $shopId = '260***'; $apiKey = '4683****'; $apiPassword = '1T1ea7****'; $CCY = 'RUB'; $amount = 1.12; // 71231234567. $phone = null; // ID $txnId = 'habr'.rand(1,90000); $params = [$apiKey, $CCY, $shopId, $amount, $txnId]; if (null !== $phone) { $params = [$apiKey, $CCY, $shopId, $amount, $phone, $txnId]; } // $params[] = md5($apiKey); // "|" $paramsStr = implode('|', $params); // $signature = hash('sha512', $paramsStr); // query $query = http_build_query([ 'from' => $shopId, 'to' => $phone, 'txn_id' => $txnId, 'summ' => $amount, 'api_id' => $apiKey, 'ccy' => $CCY, 'signature' => $signature ]); // url $url = 'https://bill.qiwi.com/order/external/create.action?'.$query; Collective r & d
I propose, as an experiment, to decide together how to develop the protocol. We have not solved several technical issues and suggest you to think with us how to develop the protocol. For this, a vote has been added at the end of the article.
The main problem remains the lifetime parameter, which is responsible for the lifetime of the account. In the existing protocol, it was transmitted in minutes, and the bill was issued immediately after the redirection. In the new - the invoice can be issued much later, especially if the link was sent by email. Therefore, most likely, you need to add a new parameter with an absolute date. For example, in ISO 8601 format (2016-09-12T00: 00: 00), which is used in REST. But do they need seconds there? And ask whether to encode ':' in '% 3A', or replace it with '-', since many still pass the success_url without url coding and knock on support with questions. Most likely, the new parameter should also be included in the calculated signature.
The updated protocol is difficult, but allows you to make mass mailings. The main problem is the unique transaction id that will need to be generated when creating the link. For mass mailings with the purchase of a particular item, this may be difficult. The solution would be a set of purchase id and user account in the store, but then the user can buy something only once. The problem could be solved by making new parameters and removing the restriction on uniqueness. True, there are doubts that this is required by the market. Let's vote?
For dessert
The new protocol is already ready for connecting partners, but so far it is activated only through the support service. If you want to take part in testing, write to cms@qiwi.ru or contact support.
You can estimate the current status of the payment page here . Happy programmer!
PS I invite a Java developer with good experience in implementing the REST API to join our team in launching the new ishop.qiwi.com and qualitatively turn the world around for thousands of our partners this year.
Source: https://habr.com/ru/post/309772/
All Articles