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

Introduction

In this series, we will consider the process of authorization by 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 first part of the series describes the exchange between the POS terminal and the bank processing.

And int this article we considering not terminal models (for example, Ingenico / Verifone / Castles, etc.) and not their classification by communication types (for example, Ethernet / GPRS / Wi-Fi, etc.). You can find such articles in the Internet at the moment. We will touch upon the «internal component» of the payment equipment, i.e. the perspective from which POS-terminals see Payment systems and EMVCo.

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: An acquirer (see below) sends an authorization request to the Payment system (hereinafter referred to as 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 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 merchant is a retail and service outlet (hereinafter the RSO) with the 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.

ISO 8583 protocol, main provisions

ISO 8583 is the protocol standardizing the online exchange of financial messages during the use of the bank cards and other means of payment. It is effectively the default protocol in this field.

Since ISO 8583 protocol is quite well-known, we will not rest upon the details of it, and those who are interested in it, can read about it here, for example, and also search on the Internet.

The key things are the following:

1) Message Type Identifier (MTI) is a four-digit value. Each digit has its function and contains information on the version of the protocol (1st digit), message class (2nd digit), functionality (3rd digit) and the originator of the transaction (4th digit). E.g., MTI=0110, where:

• The first digit 0 means a 1987 version of the protocol (in fact, two versions are in use: 0 = a 1987 version, 1 = a 1993 version, Such PCs as Mastercard, Visa, Union Pay and NSPK (Russian National Payment Card System) operate on a 1987 version and American Express operates on a 1993 version).
• The second digit 1 is the message class (the primary possible meanings are: 1 = authorization, 2 = financial, 3 = action with the data files, 4 = reversal, 5 = reconciliation (export/reconciliation of totals), 6 = administrative, 8 = network management).
• The third digit 1 = response (the primary possible meanings are: 0 = inquiry, 1 = response, 2 = advice, 3 = response to advice).
• The fourth digit 0 = the exchange is originated by the acquirer (the primary possible meanings are: 0 = the exchange is originated by the acquirer, 1 = acquirer repeat(repeat of a message originated by the acquirer), 2 = the exchange is originated by the issuer, 3 = issuer repeat(repeat of a message originated by the issuer), 4 = the exchange is originated by the PS, 5 = PS repeat(repeat of a message originated by the PS)).

2) Bitmaps. In total, there are three of them:

• The first Bitmap can include the data elements (also known as the «fields») from 1 to 64.
• The second Bitmap can include fields from 65 to 128.
• The third Bitmap can include fields from 129 to 192.

3) Data elements. Data elements, i.e., fields and various combinations thereof, ensure that all parties of the settlements can definitely identify any given message type. And one of the key elements is Field 3 (Processing Code), or more specifically, its first two positions (Transaction Type). Their content may vary depending on the online interface (i.e., the specification) of one or another PS. However, the primary values are the following:

• 00 - Purchase.
• 01 - ATM cash disbursement.
• 02 - Debiting related to a previously sent crediting transaction.
• 09 - Purchase associated with cash disbursement.
• 20 - Refund.
• 30 - Balance inquiry.

I.e, for example, if the issuer receives an MTI 0100 message where the first three elements of Field 3 = 00, the issuer will identify it as a Purchase; or, if Field 3 = 09, as a purchase associated with cash disbursement, etc.

The above-mentioned information should be enough to get the basic idea of how ISO 8583 protocol works. Again, the structural content of the fields is unique for each type of transaction and for each PS, but their consideration is beyond this article.

Authorization: Exchange structure

In terms of structure, the authorization process is composed of two components:

1. The data exchange between the POS terminal and the host (PC) of the acquirer (POS to Host, a.k.a. P2H).
2. The data exchange between the acquirer, the PS and the issuer (Host to Host, H2H).

Let us consider below the first of the said stages.

P2H (POS to HOST)

The information exchange between the POS terminal and the PC originates the entire information chain for the purpose of acquiring.

P2H can be performed in accordance with the internal protocols of a specific acquiring host or based on ISO 8583 protocol. This implies customization of this protocol, one of the characteristic features of which is the use of Field 24 (Function Code) which is not in the specifications of the PS and through the analysis of which the host «understands» how exactly a particular request should be processed. The completion of Field 24 depends on the vendor’s (developer’s/ provider’s) specifications of one or another PC, so we will only describe the general concept.

Suppose that POS has sent 0200 message, where Field 3 = 00x, and Field 24 = 200. The host will «understand» that this is a Purchase transaction and send it for processing in accordance with the other factors such as the affiliation of the card (On-Us/Off-Us, i.e., whether the card is «our» (On-Us) or of a third-party issuer (Off-Us)), of a PS, etc.

Another example: POS has sent 0200 message, where Field 3 = 20x, and Field 24 = 200. The host identifies such a transaction as the Refund.

Or: If POS has sent 0400 message, Field 3 = 00x, Field 24 = 400, it is the Reversal of the full amount of purchase. If 0400 + Field 3 = 00x, Field 24 = 401, it is the Reversal of a part of the amount of the purchase. Although the above-provided data is hypothetical, we suppose that the concept itself is clear.

Another characteristic feature is the customization of some fields of ISO 8583 protocol, e.g., the aforementioned Field 3, where the use of the values other than those specified on the online interfaces of the PS, becomes acceptable. The same can concern Field/s 47 and/or 48, the use of which for the purpose of P2H has a functionality other than the one specified in the specifications of the PS. The same is true for some other fields of ISO 8583 protocol.

Hence, an important thing that should be taken into account is that P2H dialect of ISO 8583 protocol IS NOT REQUIRED to be identical to a dialect of one or another PS. I.e., suppose that during the processing of Visa card by a POS terminal the set of elements in the p2h message may or may not meet the specifications of Visa PS. In this case, the Host to Host data exchange with the PS has to be performed in strict accordance with any given Payment system.

The main types of messages that are, in one way or another, used by all PCs based on a 1987 version of ISO 8583, are:

• 0100 - Authorization message.
• 0101 - Authorization message, repeat.
• 0200 - Financial message.
• 0201 - Financial message, repeat
• 0300 - Transfer of data files (e.g., when the documents are exported from the log of the POS terminal).
• 0400 - Reversal.
• 0401 - Reversal, repeat.
• 0500 = Reconciliation (Export/Reconciliation of totals).
• 0800 - Communication test. In particular, some PCs use the MTI 08xx messages for the transactions of Download/ Change of the cryptographic keys. In this case, the relevant Function Code (Field 24) is used.

The PCs working with ISO 8583:1993 version usually use the following MTIs:

• 1100 - Authorization message.
• 1101 - Authorization message, repeat.
• 1200 - Financial message.
• 1201 - Financial message, repeat
• 1400 - Reversal.
• 1401 - Reversal, repeat.
• 1500 = Reconciliation (Export/Reconciliation of totals).
• 0804 - Link test.

Transaction patterns

Some PCs and, consequently, some POS terminals that interact with them, allow for the use of more than one transaction pattern. The most common of them are 0100/0110 and 0200/02x0 patterns.

1. 0100/0110 transaction pattern means that the POS terminal sends an MTI 0100 message (Authorization) to the host and receives 0110 message (Response to authorization) in response. Then, for the purpose of the merchant’s end of day procedure, the POS terminal sends a 0500 message (Reconciliation of totals), which, in turn, originates the transaction-by-transaction MTI 03xx messages (Transfer of files). Based on the 0300 messages, the host generates the financial MTI 02xx messages (Financial) that are written in the Database (DB) of the Processing center. Although many acquirers have been using this pattern up to this day, it should be noted that its applicability only consists in the export of offline transactions support (i.e., transactions approved without accessing the issuer’s host) on the devices with the necessary configuration and the respective Terminal Type (e.g., on a Type 22 POS). In all other cases, it is pointless.

2. Transaction pattern 0200/02x0 means that the POS terminal sends 0200 message (Financial) to the host. In this case, it is not necessary to send 0500 message (Reconciliation) because the financial message is already written online in the Database. The disadvantage of this pattern is that the support of offline transactions is completely impossible within such a pattern. However, if the use of offline is not expected (let us remind that it is effectively out of use in the Russian Federation anyway), 0200/02x0 pattern is much more secure and preferred because it incurs no risk of losing the transactions log of the POS terminal if it fails before the end of the day.

Such are the key things of the P2H exchange.

The next part will be about the matters of information exchange between the acquirer and the PS and the issuer.

Our Payment Solutions