Acquiring: Authorization by Bank Card, Protocols and Exchange Nodes. Part 2, «HOST to HOST»

Introduction

In this series, we will consider the process of authorization through a bank card as well as the basic nodes and algorithms thereof: the exchange between the POS terminal and the bank processing as well as the information interaction between the acquirer, the payment system and the issuer. The second part of the series describes the exchange between the acquirer, the PS and the issuer.

Terms and Definitions

Authorization is the process of data exchange between the parties of a transaction through a bank card or other means of payment (e.g. mobile wallet, etc.). A standard exchange chain is as follows:

The acquirer (see below) sends an authorization request to the Payment system (hereinafter referred to as the PS), and the PS sends it to the issuer. The issuer performs all the necessary checks such as security checks, checks of funds available on the card account, and other checks based on which a response (affirmative or denial) to the authorization request will be sent. The response to the authorization request will be sent on the return route. I.e., to the PS first and then to the acquirer.

POS-terminal (POS - Point Of Service) is a device providing the technical capability to service the cards and other means of payment.

The issuer is a financial institution (bank or another financial organization) that has issued a card.

The acquirer is a financial institution (bank or another financial organization) that ensures the cards servicing by the merchant.

The issuer and the acquirer have the name common to them from the viewpoint of the payment systems: Party. Hereinafter we will use all three terms depending on the context.

The merchant is a retail and service outlet (hereinafter the RSO) with the technical capability to take bank cards.

The cardholder is a holder of a card with the right to perform a set of transactions permitted by the issuer.

The processing center (PC) is the software and hardware appliance providing the technological capability of the information exchange between the internal and external parties of the settlements within one or another service (acquiring, in our case).

Another relatively common designation of the PC is the “Banking Host”, or simply the «Host». I.e., a node serving as the server within the classic customer-server architecture. In the hereafter, we will use both the PC acronym and the term «host» and its derivatives.

H2H (Host to Host)

Introduction to ISO 8583 protocol and its basic provisions are described in the previous part of this series. In this article, we will consider the data exchange between the acquirer, the PS and the issuer (Host to Host, H2H).

Now then, a POS to HOST transaction is sent to the acquirer’s PC. Consequently, the acquiring host carries out the necessary procedures, such as:

1. Definition of the transaction type;
2. Definition of the card/device type and its parameters;
3. Cryptographic procedures (check of the terminal keys and/or card keys);
4. Check of the logical content of the ISO 8583 message (matching of the fields and analysis of their correlation within the transaction defined during step 1);
5. Message routing to a respective authorization channel;
6. Receipt of the response from the authorization channel;
7. Generation of the response message to the POS.

Let us briefly consider each stage.

1. Definition of the transaction type: Analysis of the message type (MTI), the content of Field 3 (Processing Code), Field 24 (Function Code) and some other values of the inbound message.

2. Definition of the card/device type: PC analyzes the device parameters (in our case, the POS terminal), and also checks the acceptability of the given type of transaction carrying out thereon. Besides that, the PC analyzes the card parameters: it defines its affiliation («On-Us» or of a third-party issuer (Off-Us)). If the card is «On-Us», the check ceases and the host proceeds to stage 3. If the card is «Off-Us», the check of affiliation to a certain PS will be carried out as well as the analysis of its geographical attachment.

3. Cryptographic procedures: in the case of a POS, a PC analyzes the availability/validity of the cryptographic values such as the encryption keys. In the case of «On-Us» card, it analyzes the existence/validity of the CVV2/CVC2, ARQC and some other parameters depending on the method by which the card is read (chip/magnetic stripe, etc.). In both cases the respective adapter of the PC exchanges with the special cryptographic equipment (Host Security Module (HSM). Another common expansion of this abbreviation is Hardware Security Module. In the case of «Off-Us» card, such procedures as the check of the PIN block existence (if the online PIN is selected as the CVM method), and some other procedures are carried out.

4. Check of the logical content of the ISO 8583 message: analysis of the existence/content of all the necessary data, i.e., fields characteristic for one or another transaction. Since on this stage of exchange, the question is the analysis of the inbound message from POS, the check is carried out in compliance with a specific P2H specification of one or another PC.

5. Message routing to a respective authorization channel: based on the data gathered on the stages 1 to 4, a host decides to which channel/adapter it sends the message. There are two obvious scenarios:

• A) In the case of «On-Us» card, the message is to be sent to the issuer’s Database where the internal checks such as the card contract status (Active/Expired/Blocked, etc.), the availability of the funds and other checks characteristic for a specific transaction type are carried out.
• B) In the case of «Off-Us» card, the message is to be routed to a relevant channel/adapter of one or another Payment System - Mastercard, Visa, American Express, Union Pay, etc. The Host converts, or «customizes», the messages to comply with a specific PS specification. Suppose that the authorization is carried out through an American Express card. In this case, a host customizes the message by «converting» it from 0100 to 1100 and adding/modifying the content of all fields required for the online specification of American Express. The same is true for all Payment Systems.

6. Receipt of the response. This stage is clear without any additional clarifications. The Host receives a response message and analyzes its Response Code (RC).

7. Generation of the response message. During this stage, a PC carries out the «reverse» conversion of a message from the PS’s dialect to the P2H dialect, following which sends it to the POS.

Such is the general internal logic of the work of the acquiring host. It should be noted that the above scheme is a kind of a generalized and averaged description, which is why there can be some additions/modifications within it that are characteristic for one or another PC.

Principles and Characteristic Features of the Routing from a PS

Nowadays, there is the following procedure of the routing of the transactions:

• Russian issuer-emitted card transaction will be sent to the respective authorization channel of the NSPK (Russian National Payment Card System), whence the NSPK will send it to the issuer. In this case, all characteristic features of the interface of one or another PS will remain. So to speak, from the technical perspective, the NSPK-Mastercard authorization channel will be an equivalent of the «direct» authorization channel of the Mastercard. Of course, it is the same with the other PS’s.
• Foreign Bank-emitted card transaction will be sent to the «direct» channel of one or another PS (Visa, Mastercard, etc.).

This logic has been relatively recently implemented, and its goals are clear: in the case of any political «collisions», the Payment Systems will have no technical capability to stop the card traffic inside the Russian Federation. In the «short term», at least.

The mechanism used to carry out any routing is based on the BIN (Bank Identification Number). BIN consists of the first 6 or 8 digits of the card number which unambiguously determine the card’s affiliation to one or another issuer. BINs represented in the form of so-called «BIN tables» are regularly sent by the Payment Systems to all Parties using a special format that one or another host is capable to «understand». During the transaction, a PC analyzes the BIN tables and, based on the data acquired, decides which authorization channel a transaction should be sent to.

Types of Messages and Schemes of Exchange

There are two schemes of information exchange with the PS:

1. Single Message System (SMS) is a «one-pass» scheme within which a Party exchanges financial messages with a PS (i.e., the MTI 0200 messages). Some services of the Visa payment system and some services of the NSPK payment system operate in our region using the SMS. It should be noted, however, that all PSs have one technical capability or another to operate in the SMS mode. However, for various reasons, this scheme is still not widely spread in our region.

2. Double Message System (DMS) — «two-pass» scheme. In this case, the first «pass» is considered an online authorization during which a Party exchanges the MTI 0100 authorization messages with the PS. The second «pass» is the clearing (we will further tell about it in broad strokes.)

DMS is universally used in our region (being, virtually, the «de facto standard») because it is considered the most flexible.

Clearing

The clearing is the process of the generation and export to the PS of the special-format package files containing the information on each transaction carried out over a certain period. The clearing export procedure can be attached to the so-called End Of Day (EOD) or can be performed at any other time defined by the acquirer and approved by the PS, including various times a day. Each transaction record in a clearing file has the name the First Presentment and is associated with the authorization message using a special identifier.

When a PS receives a clearing file from the acquirer, the PS checks its validity. If the check is successful, the package file is generated for its sending to the issuer. If the acquirer’s clearing file contains any errors, the PS denies it until they are corrected, following which the procedure runs again.

After the clearing messages exchange, the Mutual Settlements procedure is initiated, i.e., the actual transfer of funds between the PS, the Parties and the Merchants. However, that stage is beyond this article.

It is important that when operating within the DMS the export of the clearing by the acquirer is critical. It means that if the acquirer sends the authorization message and receives a successful response thereto, but doesn’t send this message in the clearing, the funds will return to the cardholder’s account after some time.

Also, if the acquirer sends the authorization message and receives a successful response thereto, but fails to meet the deadline defined by the PS for the export of the respective clearing (depending on the transaction type and the PS, the deadlines are 3 to 9 days), it can find itself in the so-called Latest Presentment. For such occasions, the PSs have various sanctions against the acquirer.

Such are the general principles of the information exchange between the PSs and the Parties. In the next part, we will tell you about the errors that occur during the online exchange.

Our Payment Solutions