Payment technologies – just about complicated
Let’s talk about payment technologies and what happens when a client wants to pay for a service on the website or in the Internet bank, make a transfer, or we just need to set up integration with an aggregator, store or payment system in order to display their services in their remote service channels.
A series of articles will be presented here that will help novice IT specialists dealing with payment technologies answer the question: “how to write an outbound gateway with a payment system or aggregator”, “how to resolve the issue with reconciliation discrepancies”, how to implement integration with an international payment system …
Make yourself comfortable, it will be interesting.
Part 1: Making and confirming the payment
To pay for services, the client, as a rule, is authorized in the Internet bank that issued his card: To the bank – the issuer of his card.
Further, in the Internet bank, he chooses a service for payment: replenishment of a mobile phone, payment for the Internet or housing and communal services.
In the base of a service provider, for example, a cellular operator, the client has its own unique identifier – a phone number.
To pay for the service, the client enters his ID and the amount of replenishment, clicks the “confirm payment” button.
And then it displays a pre-check with the replenishment identifier and the replenishment amount. He confirms the payment and then the Internet bank displays the receipt for him. The happy client leaves. The money “instantly” goes to his phone number.
This is the case for the client. Let’s see how it looks inside the systems.
Our online messaging will consist of several members:
Showcase – in this case, the client’s Internet Bank;
Client’s bank – he is the operator for the transfer of funds, he is also the Issuing Bank that issued the client’s card, and he is also the settlement Bank for the transfer of client funds to the service provider;
Service Provider – A legal entity that provides services for crediting funds to the Supplier, it is often called the “Merchant”. The service provider has direct contracts with many service providers, and in order for the Bank not to set up integration with each of them, there are intermediary companies on the market: service providers, also called aggregators, payment systems. They have already set up integration with Service Providers and provide a large number of services for a certain percentage;
Our mobile operator is a Service Provider;
Both the Service Provider and the Service Provider have their own clearing banks. As a result, the Service Provider Bank will transfer funds offline to the Service Provider’s account in order to be credited to the client’s account. But more on that in the following articles.
I will use the entities: Bank, Merchant and Showcase to describe online interaction within systems.
The central figure in our interaction is the client’s bank.
The Bank’s task is not only to check the availability of funds from the client, but also to deliver them to the service provider. To fulfill this condition, the Bank, as a rule, writes two gateways or uses the current ones:
Incoming: from Showcase to Bank;
Outgoing: from the Bank to the Merchant;
Both of these gateways can work both according to the same protocol, and according to different ones.
We will consider the simplest option: the Bank’s showcase, the Bank and the Merchant work using one end-to-end protocol, represented by only two methods: check and pay.
The description of the process of making and confirming the payment in this case is as follows:
Description of the process of making and confirming the payment
The client chooses a service;
The Bank Showcase checks the availability of the service in its Database;
2.1 If the service is found, generates a request to the Bank for holding funds in Processing. Next, it generates a request for the possibility of making a check payment:
2.2 If the service is not found, ends the process with an error, the client leaves;
Showcase initiates check;
The Bank receives a check request. Then the Bank routes the request to the Merchant;
The merchant accepts the request, checks the payment;
5.1 If enrollment is possible, sends success, the customer is shown a guest bill. The Bank’s system is awaiting confirmation of the payment;
5.2 If the deposit is not possible, the Bank sends an error code, the storefront completes the process, the process is impossible, the client leaves;
The client gets acquainted with the bill, clicks the “confirm payment” button. Showcase initiates pay;
The bank assigns a transaction ID and immediately sends a response to the storefront;
The funds are credited to the Merchant already offline. The Bank initiates pay and, if crediting is possible, the Merchant assigns his transaction ID and sends a successful response to the Bank. And if enrollment is impossible – you ask? Then the Merchant sends a response to the Bank with an error code, and the Bank automatically refunds the funds to the client on the same day.
Now we will consider the format of the request and response for each of the methods, what they are responsible for and what they are for.
CHECK – payment processing
The method is responsible for making the payment possible. At this step, the availability of the service is checked on the storefront, in the Bank and at the Merchant. The Merchant, in turn, online, can go to the Supplier and check the validity of the replenishment identifier with the Supplier, and, if it is not found or an error, reject the payment.
Very often, at this step, the minimum requirements for the response time of the response to the request from the Merchant are laid down, since the client will not wait for the Bank Showcase, the Bank itself and the Merchant to check the availability of the service.
A distinctive feature of this step is also the calculation of the commission. Commissions are:
The upper, or hot, is the commission from the client in excess of the payment body (the amount credited);
Low or cold, this is the commission that the Merchant Bank pays;
Mixed – in this section we will not talk about them;
In our example, only the commission from the client is calculated on check, the lower and mixed commissions are calculated separately. More on this in the following articles.
The structure of the check / XML request, the gateway of the Showcase – Bank contour:
<check>
<payment>
<Time>2021-02-08T00:16:19</Time>
<type>CARD</type>
<type_number>505266***2025</type_number>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
</payment>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</check>where
Time – payment date;
type – the type of the write-off source;
type_number – masked PAN of the card (note: PAN – card number) by PCI DSS;
code – the code of the transfer currency, in the example, rubles;
amount – the amount credited or, in other words, the payment body
commission_amount – amount including the upper commission;
service – digital identifier of the service, which checks whether there is such a service at all in the Bank and on the storefront;
account – container with the replenishment identifier, in our case, the phone number;
When a client clicks the icon with a paid service in the storefront, the first thing the system does is check the availability of the service, and if it is available, then it goes to processing to check the source of the charge (Type and type_number fields)
Further, if there is money, it checks the possibility of crediting money to the phone number (phone_number in the value 86248541234)
Wait a second – you ask. Something doesn’t add up here. How can I check the availability of funds on the client’s card using the masked PAN in the type_number field?
That’s right, attentive readers have noticed that this cannot be done using a masked PAN.
Processing authorization is performed before check and it is a separate method and a separate process, look at the process diagram above. We are already working with a masked PAN during the payment process. at this step, we check the possibility of making a payment, and not the presence of funds on the client’s card.
Next, we form a request to the Merchant.
We do not indicate either the PAN or the type of the source of debiting, we are only interested in the possibility of making a payment for a specific service.
Structure of a check / XML request, gateway of the Bank – Merchant contour:
<check>
<payment>
<Time>2021-02-08T00:16:19</Time>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
</payment>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</check> In the response, the Merchant returns all the same fields, but an additional container appears with the processing status of the operation, as well as the transaction ID in the id field
Structure of the check / XML response, gateway of the Merchant – Bank contour:
<check>
<payment>
<Time>2021-02-08T00:16:20</Time>
<id>123456789</id>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</payment>
<StatusInfo>
<status_id>Seccess</status_id>
<disсriptin>Успех</disсriptin>
<errorCode>0</errorCode>
</StatusInfo>
</check>Such a response will mean that the Merchant is ready to confirm the payment by the client.
In the response, we will have a temporary transaction id of the Merchant, as well as the status of payment processing: status_id == Success (success) and an error code equal to 0 (success) in the errorCode field
Successful transaction statuses do not always come to us and we do not always have error codes, but we will talk about this in the following articles.
We save the response and enrich it with the fields necessary for the storefront, assign the merchant’s transaction identifier – the identifier in the Bank, and send the response to the storefront.
The structure of the check / XML response, the gateway of the contour Bank – Showcase
<check>
<payment>
<Time>2021-02-08T00:16:20</Time>
<type>BOUND_CARD</type>
<type_number>427684***3619</type_number>
<id>123</id>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</payment>
<StatusInfo>
<status_id>Success</status_id>
<disсriptin>Успех</disсriptin>
<errorCode>0</errorCode>
</StatusInfo>
</check> The client sees the screen form of the bill, which each of us is familiar with: there will be the payment amount, date, as well as the identifier of the replenished service.
If the client agrees with everything, he clicks the “pay” button. Now the payment can be canceled only by a written order of the payer, as a rule – by contacting the Bank in person.
In the request, the storefront can transmit both all the fields from the previous check response, or just the amount of the payment and the ID of the transaction received in the previous step.
We will use the first option.
PAY – confirmation of payment
Structure of a pay / XML request, gateway of the Showcase-Bank contour:
<pay>
<payment>
<Time>2021-02-08T00:16:25</Time>
<type>CARD</type>
<type_number>505266***2025</type_number>
<id>123</id>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
</payment>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</pay>The bank registers the payment, and immediately sends a response with an intermediate status of processing the transaction “in progress” in response to the storefront
Pay / XML response structure, gateway of the Bank – showcase contour:
<pay>
<payment>
<Time>2021-02-08T00:16:20</Time>
<type>CARD</type>
<type_number>505266***2025</type_number>
<id>123</id>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</payment>
<StatusInfo>
<status_id>Inprogress</status_id>
<disсriptin>В проведении</disсriptin>
<errorCode>0</errorCode>
</StatusInfo>
</pay>The client is printed a receipt for payment acceptance, with the seal of the Bank, and he leaves.
Wait – you ask. Does the Bank not send payments to the anti-fraud system? It sends, of course, just so that clients have no problems with translations to the address of the “security services from places of deprivation of liberty.” To do this, each payment is sent for verification by the system and only after that to the Merchant. But this process is unique in every organization and there are no general rules.
But you haven’t visited the Merchant yet, haven’t confirmed the payment with him, haven’t registered the payment with him, and you’re already letting the client go – you ask again?
That’s right, the client will not wait until we go off and register the payment with the Merchant, and he will turn to his suppliers on remote systems. We have already checked the possibility of making a payment online at the previous check step, and now we can release the client with the Bank’s seal “in progress” and register the payment with the merchant offline.
To register a payment with a merchant, for the passed id of the storefront transaction, we find the merchant’s transaction from the previous step and with it we already register the payment.
Pay / XML request structure, gateway of the Bank – merchant contour:
<pay>
<payment>
<Time>2021-02-08T00:16:25</Time>
<id>123456789</id>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
</payment>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</pay>Pay / XML response structure, merchant circuit gateway – Bank:
<pay>
<payment>
<Time>2021-02-08T:16:25</Time>
<id>123456789</id>
<code>643</code>
<amount>20100</amount>
<comission_amount>20241</comission_amount>
<service>123456789</service>
<account>
<name>phone_number</name>
<value>86248541234</value>
</account>
</payment>
<StatusInfo>
<status_id>Success</status_id>
<disсriptin>Успех</disсriptin>
<errorCode>0</errorCode>
</StatusInfo>
</pay>In response, the merchant reports the status of the transaction processing, which can take the status of success, in execution, or, if the payment was declined, an error.
Two statuses are final, and one is intermediate.
We can say that on these statuses, the obligations of both the Bank and the Merchant to the client are completed.
Wait, wait – you summarize. How are commitments completed? After all, the client left with a check, where it is written that the Bank only accepted the operation for execution, and the Merchant can reject the operation, and the client has already left, what to do?
Yes, this happens quite often, and to solve this problem there is a separate process for requesting the final status of the operation both on the side of the storefront and on the side of the Bank, but more on that in the following articles.
