For my project, I needed to implement the ability to transfer from card to card. To officially connect to the interface of any bank, it is necessary to conclude an agreement and fulfill a number of conditions. Therefore, it was decided to create a gateway to the bank’s public page. For these purposes, two banks were chosen: Tinkoff and BIN Bank, which provide the opportunity to transfer to “their” cards without commission. You can find out more about tariffs and restrictions on transfers on the relevant pages of banks. This article provides a brief description of the operation of the gateway that implements the functionality of accepting payments to a card.
It is required to implement a transfer from any card to a pre-selected card, with support for the 3DSecure authorization procedure. 3DSecure is a secure user authorization protocol for CNP transactions (without the presence of a card). You can read more details on specialized websites; the diagram below shows a simplified diagram of how it works from the user’s point of view.
The picture simplifies the transaction authorization mechanism, what happens “under the hood” when you make a payment or transfer from card to card and enter an SMS code for confirmation.
Let's look at it step by step:
For a deeper understanding of the process, read the relevant documents from Visa or Mastercard; this level is quite enough to solve this problem.
To ensure seamless operation of the gateway, so that the ears of the site through which the translation is made do not stick out, it is necessary to integrate into this process of browser redirection between MPI and ACS. To do this, you need to replace the address (TermUrl) received from MPI. This is the address to which PaRes will be redirected after the user completes authorization; the gateway address is entered as TermUrl in the request. This will allow the gateway to receive a response (RaRes), send it to the MPI server and, after processing the MPI response, direct the user to the page of successful or unsuccessful completion of the transaction.
The gateway works between the user's browser and the bank's page, implements input/output functions emulating the bank's page, supplements and changes data, and processes responses and errors from bank services.
The protocol for interaction with each bank was determined manually through back engineering interaction between the browser and the bank’s website; in general, the logic is the same, the difference is in the variables and transmission methods. In general, this is a bottleneck, and the functionality of the software depends on the immutability of the API; as soon as the bank changes the operation of the service, the logic of the gateway will have to be changed.
Let's take a closer look at the operating logic.
To ensure transactions are carried out, the gateway has implemented a payment page, which can be accessed at:
The URL contains the following variables:
payid – transaction ID necessary to identify the results of the payment request after the transaction is completed;
sum – transaction amount;
text – information field “Purpose of payment”.
After filling out the card data and agreeing to the terms of execution, the commission requests to carry out the operation. The size of the commission and the bank (one of two Tinkoff and BIN) through which the transfer will be made depends on the card specified in the gateway settings as the transfer recipient and the availability of the bank’s service. The gateway implements a simple routing and error handling mechanism: Tinkoff is always selected, if the bank page is not available, then the Bank's BIN page is selected.
After clicking the transfer button, you are redirected to the page of the issuing bank that issued the card (ACS), from which the debit operation will be performed. The gateway will request PaReq parameters from MPI, replace TermUrl and send the data to the user, having previously stored the transaction parameters in the cache (Redis).
After authorization is completed, PaRes will arrive at the gateway, and based on the cache data, it will forward them to the appropriate MPI, process the response and redirect the user to one of the pages (ERROR_PAGE, SUCCESS_PAGE) specified in the gateway settings.
The URL for calling the page for successful completion of the operation contains the payid variable, which transmits the results of the operation in the form of a JWT with digital signature.
JWT example:
By verifying the contents of the JWT, you can obtain reliable information about the success of the operation. The JWT token performs a function similar to PaReq and provides the ability to integrate with an external system.
This solution is a prototype of a payment gateway with which you can implement Internet acquiring (accepting card payments) on your website or social network page. You can parameterize the payment page or write your own, creatively modify the software, the main thing is to pass the amount and transaction id as input and check at the output that nothing has been creatively changed by someone else. Sources and working examples are available on github.
There is also a gateway for replenishing your VK.pay wallet, which can also be used as a payment gateway. In general, it implements the same principles; Selenium was used to implement part of the functionality, with the help of which authorization on the site and authorization to access the wallet are implemented.
IMPORTANT! Any Internet transactions are potentially dangerous, your data can be stolen, it is necessary to take precautions when conducting Internet transactions.
IMPORTANT! Criminal liability is provided for the theft of funds from other people's bank cards (Articles 159.3, 159.6 of the Criminal Code of the Russian Federation).
It is required to implement a transfer from any card to a pre-selected card, with support for the 3DSecure authorization procedure. 3DSecure is a secure user authorization protocol for CNP transactions (without the presence of a card). You can read more details on specialized websites; the diagram below shows a simplified diagram of how it works from the user’s point of view.
The picture simplifies the transaction authorization mechanism, what happens “under the hood” when you make a payment or transfer from card to card and enter an SMS code for confirmation.
Let's look at it step by step:
- Enter your card details and amount and send to the bank’s website.
- The bank turns to a specialized service (Merchant Plug-In MPI), which generates a special request PaReq, which is XML with digital signature, containing transaction parameters, as well as data where this request should be sent (Access Control Server ACS), and where to send authorization response (PaRes).
- The bank returns the user a page containing information from MPI and automatically redirecting the browser to the ACS page of the bank that issued the user's card. The user is shown a page for entering an SMS code and an SMS is sent to the phone number registered with the issuing bank.
- After entering the SMS code, the ACS server generates a page with an authorization response (PaRes), redirecting the user to the MPI page to complete the operation or refuse to perform it.
For a deeper understanding of the process, read the relevant documents from Visa or Mastercard; this level is quite enough to solve this problem.
To ensure seamless operation of the gateway, so that the ears of the site through which the translation is made do not stick out, it is necessary to integrate into this process of browser redirection between MPI and ACS. To do this, you need to replace the address (TermUrl) received from MPI. This is the address to which PaRes will be redirected after the user completes authorization; the gateway address is entered as TermUrl in the request. This will allow the gateway to receive a response (RaRes), send it to the MPI server and, after processing the MPI response, direct the user to the page of successful or unsuccessful completion of the transaction.
The gateway works between the user's browser and the bank's page, implements input/output functions emulating the bank's page, supplements and changes data, and processes responses and errors from bank services.
The protocol for interaction with each bank was determined manually through back engineering interaction between the browser and the bank’s website; in general, the logic is the same, the difference is in the variables and transmission methods. In general, this is a bottleneck, and the functionality of the software depends on the immutability of the API; as soon as the bank changes the operation of the service, the logic of the gateway will have to be changed.
Let's take a closer look at the operating logic.
To ensure transactions are carried out, the gateway has implemented a payment page, which can be accessed at:
Code:
http://<gateway address>/pay/page?payid=123456&sum=100&text=TestThe URL contains the following variables:
payid – transaction ID necessary to identify the results of the payment request after the transaction is completed;
sum – transaction amount;
text – information field “Purpose of payment”.
After filling out the card data and agreeing to the terms of execution, the commission requests to carry out the operation. The size of the commission and the bank (one of two Tinkoff and BIN) through which the transfer will be made depends on the card specified in the gateway settings as the transfer recipient and the availability of the bank’s service. The gateway implements a simple routing and error handling mechanism: Tinkoff is always selected, if the bank page is not available, then the Bank's BIN page is selected.
After clicking the transfer button, you are redirected to the page of the issuing bank that issued the card (ACS), from which the debit operation will be performed. The gateway will request PaReq parameters from MPI, replace TermUrl and send the data to the user, having previously stored the transaction parameters in the cache (Redis).
After authorization is completed, PaRes will arrive at the gateway, and based on the cache data, it will forward them to the appropriate MPI, process the response and redirect the user to one of the pages (ERROR_PAGE, SUCCESS_PAGE) specified in the gateway settings.
The URL for calling the page for successful completion of the operation contains the payid variable, which transmits the results of the operation in the form of a JWT with digital signature.
JWT example:
Code:
eyJhbGciOiJIUzUxMiJ9.eyJqdGkiOiI2Njk2NzFlYi1mYmZlLTVlMTMtYTdkZi05NDEwZjg1N2U5ODkiLCJpYXQiOjE1NzE5MDg5MjgsInN1YiI6ImZpeGVkIiwiaXNzIjoicnUucGhvbmU0cGF5IiwicGF5X2lkIjoiMTIzNDUiLCJzdW0iOiIxMDAuMCIsInRyYW5zYWN0aW9uX2lkIjoiODY4MTE5ODYzIn0.c-IK3FowoR_tVe3-cpT7-rmA4EQhYy8rZkWrWASHZlc0ZzzpQont5XriCSzuDaY7jf7iIC8ZAxknAMwmTNmAHgBy verifying the contents of the JWT, you can obtain reliable information about the success of the operation. The JWT token performs a function similar to PaReq and provides the ability to integrate with an external system.
This solution is a prototype of a payment gateway with which you can implement Internet acquiring (accepting card payments) on your website or social network page. You can parameterize the payment page or write your own, creatively modify the software, the main thing is to pass the amount and transaction id as input and check at the output that nothing has been creatively changed by someone else. Sources and working examples are available on github.
There is also a gateway for replenishing your VK.pay wallet, which can also be used as a payment gateway. In general, it implements the same principles; Selenium was used to implement part of the functionality, with the help of which authorization on the site and authorization to access the wallet are implemented.
IMPORTANT! Any Internet transactions are potentially dangerous, your data can be stolen, it is necessary to take precautions when conducting Internet transactions.
IMPORTANT! Criminal liability is provided for the theft of funds from other people's bank cards (Articles 159.3, 159.6 of the Criminal Code of the Russian Federation).
