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 operations (without the presence of a card). You can read more on specialized sites, the diagram below shows a simplified diagram of how this works from the user's point of view.
The picture shows a simplified mechanism for authorizing a transaction, what happens “under the hood” when you perform a payment or transfer operation from card to card, and enter an SMS code to confirm.
Let's consider step by step:
- Enter card details and amount, and send to the bank's website.
- The Bank uses a specialized service (Merchant Plug-In MPI), which generates a special PaReq request, 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 it authorization response (PaRes).
- The bank returns to the user a page containing information from MPI and automatically redirects 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 in 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 Visa or Mastercard documents, this level is enough to solve this problem.
To ensure seamless operation of the gateway so that the ears of the website through which the translation is not sticking out, it is necessary to integrate into the browser redirection process between MPI and ACS. To do this, replace the address (TermUrl) received from MPI. This is the address to which PaRes will be redirected after the user completes authorization, as the TermUrl, the gateway address is entered in the request. This will allow the gateway to receive a response (RaRes) to 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 page, implements input / output functions emulating the bank page, supplements and changes data, and processes responses and errors from the bank services.
The protocol of interaction with each of the banks was clarified manually by back engineering of the interaction between the browser and the bank’s website, in general, the logic is the same, the difference in variables and transfer 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 also have to be changed.
Let's consider in more detail the logic of work.
To ensure operations in the gateway, a payment page is implemented, the call to which is carried out at the address:
http://< >/pay/page?payid=123456&sum=100&text=Test
The URL contains the following variables:
payid - transaction ID required to identify the results of a payment request after a transaction is completed;
sum - transaction amount;
text - information field “Purpose of payment”.
After filling in the card data, agreeing to the terms of execution, a commission request is issued for the operation. The size of the commission and the bank (one of the two Tinkoff and BIN) through which the transfer will be made depends on the card specified in the gateway settings as the transfer receiver and the availability of the bank service. A simple mechanism for routing and error handling is implemented in the gateway: Tinkoff is always selected, if the bank page is not available, then the BIN Bank page is selected.
After clicking the transfer button, the system is redirected to the page of the issuing bank that issued the card (ACS), from which the debiting operation will be performed. The gateway will request PaReq parameters from MPI, replace TermUrl and send the data to the user, after remembering the transaction parameters in the cache (Redis).
After authorization is complete, PaRes will go to the gateway, and based on the cache data, it will forward them to the corresponding MPI, process the response, and redirect the user to one of the pages (ERROR_PAGE, SUCCESS_PAGE) specified in the gateway settings.
The URL to the page for successful completion of the operation contains the variable payid, which transmits the results of the operation in the form of a JWT with digital signature.
JWT example:
eyJhbGciOiJIUzUxMiJ9.eyJqdGkiOiI2Njk2NzFlYi1mYmZlLTVlMTMtYTdkZi05NDEwZjg1N2U5ODkiLCJpYXQiOjE1NzE5MDg5MjgsInN1YiI6ImZpeGVkIiwiaXNzIjoicnUucGhvbmU0cGF5IiwicGF5X2lkIjoiMTIzNDUiLCJzdW0iOiIxMDAuMCIsInRyYW5zYWN0aW9uX2lkIjoiODY4MTE5ODYzIn0.c-IK3FowoR_tVe3-cpT7-rmA4EQhYy8rZkWrWASHZlc0ZzzpQont5XriCSzuDaY7jf7iIC8ZAxknAMwmTNmAHg
By verifying the contents of the JWT, you can get 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 payments by card) on your website or social network page. You can parameterize or write your own payment page, creatively modify the software, the main thing is to transfer the amount and id of the operation to the 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 to replenish 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 for accessing the wallet are implemented.
IMPORTANT! Any Internet transactions are potentially dangerous, your data may be stolen, you need to take precautions when conducting Internet transactions.
IMPORTANT! Criminal liability is provided for the theft of funds from another's bank cards (Articles 159.3, 159.6 of the Criminal Code of the Russian Federation) .