Payment technologies – simply about complex things

[Tomcat]

Let's talk about payment technologies and what happens when a client wants to pay for a service on a website or in Internet Banking, 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 involved in payment technologies answer the question: “how to write an outgoing gateway with a payment system or aggregator”, “how to resolve the issue of discrepancies during reconciliations”, how to implement integration with an international payment system .

Make yourself comfortable, it will be interesting.

Making and confirming payment​

To pay for services, the client usually logs in to the Internet Bank that issued his card: the Issuing Bank of his card.

Next, in the Internet Bank, select a service for payment: replenishment of a mobile phone, payment for the Internet or utility services.

In the database of a service provider, for example a cellular operator, the client has his own unique identifier - a telephone number.

To pay for the service, the client enters his ID and replenishment amount, and presses the “confirm payment” button.

And then he is shown a preliminary receipt with the replenishment identifier and the replenishment amount. He confirms the payment and then Internet Bank displays a receipt to him. The happy client leaves. The money is “instantly” sent to his phone number.

This is true for the client. Let's see what it looks like inside the systems.

Our online messaging will consist of several participants:

• Showcase – in this case, the client’s Internet Bank;
• The client’s bank is also the operator for the transfer of funds, it is also the Issuing Bank that issued the client’s card, and it is also the settlement Bank for transfers of client funds to the Service Provider;
• Service Provider is a legal entity that provides services for crediting funds to the Supplier; it is often called a “Merchant”. The Service Provider has direct contracts with many service providers, and so that the Bank does not have 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 cellular operator is the Service Provider;

Both the Service Provider and the Service Provider have their own settlement Banks. As a result, the Service Provider's 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 future articles.

I will use the entities: Bank, Merchant and Showcase to describe online interaction within the 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:

1. Incoming: from the Storefront to the Bank;
2. Outgoing: from Bank to Merchant;

Both of these gateways can operate either using the same protocol or using different ones.

We will consider the simplest option: the Bank storefront, Bank and Merchant work using the same end-to-end protocol, represented by only two methods: check and pay.

The description of the process of making and confirming payment in this case is as follows:

Description of the process of making and confirming payment​

1. The client selects a service;
2. The Bank Storefront checks the availability of the service in its Database;
   2.1 If the service is found, creates a request to the Bank to hold funds in Processing. Next, it generates a request for the opportunity to make a payment check:
   2.2 If the service is not found, the process ends with an error, the client leaves;
3. The showcase initiates check;
4. The Bank receives a check request. Next, the Bank routes the request to the Merchant;
5. The merchant accepts the request, checks the payment;
   5.1 If enrollment is possible, sends success, the client is shown a bill. The Bank's system is waiting for payment confirmation;
   5.2 If crediting is impossible, the Bank sends an error code, the storefront completes the process, processing is impossible, the client leaves;
6. The client reads the bill and presses the “confirm payment” button. The storefront initiates pay;
7. The bank assigns a transaction ID and immediately sends a response to the storefront;
8. The Merchant is already depositing funds offline. The Bank initiates pay and, if credit is possible, the Merchant assigns its 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 returns the funds to the client on the same day.

Now let's look at the request and response format for each of the methods, what they are responsible for and what they are needed for

CHECK – making a payment​

The method is responsible for the possibility of making a payment. At this step, the availability of the service is checked at the storefront, at the Bank and at the Merchant. The Merchant, in turn, online, can go to the Supplier and check the validity of the Supplier’s replenishment ID, and, if it is not found or there is an error, reject the payment.

Very often, at this step, minimum requirements are laid down for the response time of a response to a request from the Merchant, because the client will not wait until the Bank Showcase, the Bank itself and the Merchant check the availability of the service.

A distinctive feature of this step is also the calculation of the commission. Commissions are:

• Top, or hot, is a commission from the client in excess of the body of the payment (deposit amount);
• The lower or cold one is the commission paid to the Bank by the Merchant;
• 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.

Check/XML request structure, Gateway of the Showcase – Bank circuit:

<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 – date of payment;
• type – write-off source type;
• type_number – masked PAN of the card (note: PAN is the card number) according to PCI DSS;
• code – transfer currency code, in the example rubles;
• amount – credit amount or, in other words, payment body
• commission_amount – amount including the upper commission;
• service – digital service identifier, which checks whether such a service is available at all in the Bank and on the storefront;
• account – container with the replenishment identifier, in our case – phone number;

When a client clicks on the icon with a paid service on the storefront, the first thing the system does is check the availability of the service and if it is available, it then contacts processing to check the source of the write-off (Type and type_number fields)

Next, if there are funds, it checks the possibility of crediting funds to the phone number (phone_number in the value 86248541234)

Wait a second, you ask. Something doesn't add up here. How can you check the availability of funds on a client’s card using a masked PAN in the type_number field?

That’s right, attentive readers have noticed that this cannot be done using a masked PAN.

Authorization in processing is performed before check and this is a separate method and a separate process, look at the process diagram above. When making a payment, we already work with a masked PAN, because... At this step, we check the possibility of making a payment, and not the availability of funds on the client’s card.

Next, we create a request to the Merchant.

We do not indicate either the PAN or the type of debit source; we are only interested in the possibility of making a payment for a specific service.

Check/XML request structure, Bank-Merchant circuit gateway:

<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 transaction processing status, as well as the transaction identifier in the id field

Structure of the check/XML response, gateway of the Merchant – Bank circuit:

<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>Success</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 from the Merchant, as well as the payment processing status: status_id == Success (success) and an error code equal to 0 (success) in the errorCode field

We do not always receive successful transaction statuses 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 it to the merchant’s transaction ID - an identifier in the Bank, and send the response to the storefront.

Structure of the check/XML response, gateway of the Bank – Showcase circuit

<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 a 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 service being replenished.

If the client agrees with everything, he presses the “pay” button. Now you can cancel a payment only by written order of the payer, as a rule, by personally contacting the Bank.

In the request, the storefront can transmit all the fields from the previous check response, as well as simply the payment amount and the transaction ID received at the previous step.

We will use the first option.

PAY – confirmation of payment​

Pay/XML request structure, gateway of the Showcase - Bank circuit:

<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 the intermediate transaction processing status “in progress” in response to the storefront

Pay/XML response structure, Bank circuit gateway – showcase:

<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>

A check is printed for the client confirming acceptance of payment for execution, with the Bank’s seal, and he leaves.

Wait - you ask. What, the Bank doesn’t send payments to the antifraud system? Sends, of course, just so that clients do not have problems with transfers to the “security service from places of detention.” 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 each organization and there are no general rules.

But you haven’t gone to the Merchant yet, haven’t confirmed the payment with him, haven’t registered the payment with him, and you’re already releasing the client - you ask again?

That’s right, the client will not wait until we go and register the payment with the Merchant, and he, in turn, will contact 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 stamp “in progress” and register the payment with the merchant offline.

To register a payment from a merchant, for the storefront transaction id transmitted, we find the merchant transaction from the previous step and register the payment with it.

Pay/XML request structure, Bank-merchant circuit gateway:

<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 processing status of the transaction, which can take the status of success, in progress, or, if the payment was rejected, an error.

Two statuses are final, and one is intermediate.

We can say that in these statuses, the obligations of both the Bank and the Merchant to the client are completed.

Wait, wait - you summarize. How are the obligations completed? After all, the client left with a check, which says that the Bank only accepted the transaction for execution, and the Merchant can reject the transaction, but 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 transaction both on the storefront side and on the Bank side, but more on that in the following articles.

In Part 1 we covered the basics of making a payment. We found out that the process is very simple and consists of several participants: Client, Storefront, Bank and Merchant, as well as two basic methods: check and pay.

Now let's talk about a method that will allow the Bank to avoid discrepancies when reconciling with the Merchant.

Reconciliations are the process of matching the register of accepted payments from the storefronts where the Merchant’s services are located with the register of actual payments made by the Merchant.

Simply put, the success of this reconciliation shows the Bank whether there are services where money was accepted from the Client, but not credited to the Merchant.

If all systems worked synchronously, then successful payments will be automatically uploaded to the nearest transfer register for further matching.

But what should we do if we have not received a response to the pay request or have received a response, but the Merchant’s operation is in intermediate status?

For this purpose, there is a request for the final status of the getStatus operation.

Type of interaction – asynchronous.

We initiate it in the following cases:

• The waiting time for a response to pay has exceeded the acceptable threshold. In the Bank, we set the operation to be carried out and initiate the getStatus request;
• In response to the pay request, we received the intermediate status of the operation - InProgress.

The first event occurs for any technical reason.

And the second event occurs when the Merchant is not the Provider of the services provided, but orders them from third parties and sells them to the Bank for a certain percentage. The Merchant needs time to go to the Supplier’s remote systems and give the assignment for enrollment. Therefore, in response to pay with the InProgress status, he informs the Bank: the money has been accepted, but I don’t know about the credit status. Try to find out later.

This is what it looks like in the general payment process:

1. The bank analyzes transactions where a response to the pay request was not received or where a response was received, but the operation status is intermediate: InProgress;
2. Next, it polls the Merchant system at a certain frequency: usually once every 15 minutes during the day. Next, the operation is converted into an error along the entire information exchange circuit;
3. The showcase, in turn, does the same, but in relation to the Bank.

The client has already left by this time, he has a check with the Bank’s stamp: payment has been accepted. If there are any difficulties and the Merchant does not credit the funds, Bank employees will contact him or the storefront will update the status in the client’s personal account automatically, based on the results of processing these statuses and further matching.

getStatus/XML request example

Initiating system: Bank

Recipient system: Merchant

<pay>
    <payment>
      <time>2021-02-08T00:16:25</time>
      <id>123456789</id>      
    </payment>                        
</pay>

In the request we indicate the transaction id received in response to pay. If we have not received it, the Bank's system should try to complete the payment by sending pay every few minutes, usually no more than three. Next, the operation is set to InProgress and getStatus is initiated.

Example getStatus/XML response

Initiating system: Merchant

Recipient system: Bank

<pay>       
    <payment>
      <Time>2021-02-08T:16:25</Time>  
        <id>123456789</id>         
    </payment>   
      <StatusInfo>
          <status_id>Success</status_id>
        <disсriptin>Успех</disсriptin>  
        <errorCode>0</errorCode>          
      </StatusInfo>
</pay>

In response to the getStatus request, the Merchant can also report not the final status of the operation (success or error), but the intermediate InProgress. For these cases, the same rules apply as for the case of not receiving a response to pay: we continue to poll the Merchant’s system until we receive the final status of the transaction, usually no more than 24 hours.

The structure of the request and response from the Storefront to the Bank is identical, with the exception of the names of the fields and transaction Id values.

The Bank system analyzes the value of the status_id field. Successful transactions are immediately uploaded to the nearest transfer register for matching and further reimbursement of funds to the Merchant.

There are no refunds for erroneous transactions. If in response to the getStatus request a status_id was received with an error value, the funds are automatically returned to the client’s card.

We will talk more about refunds and reconciliations in future articles.