Implementing Electronic Card Payment Systems (Artech House Computer Security Series)

2.8 Payment network and interchange messages

Terminals located at various points of service are connected to the acquirer host via the acquirer's network. The formats of (1) the payment messages generated by the terminal at the point of service and forwarded to the acquirer host and (2) the confirmation messages returned by the acquirer host to the terminal are proprietary to the acquirer's network.

In the simplest scenario, the acquirer managing the terminal at the point of service and the issuer of the card involved in the payment transaction are subscribers to the services offered by the same payment system network. This network is the property of a card association or a payment system operator that is responsible for managing the network and for settling funds between the issuer and the acquirer following a payment transaction. Each acquirer host (AH) and issuer host (IH) is connected to separate nodes of the payment network, referred to as the acquirer node (AN) and issuer node (IN), respectively. In order to increase the availability of the issuer's service, an issuer can duplicate the functionality of an IH through a second computer acting as an active reserve. The payment system operator can provide a stand-in processing facility to an issuer, through which the payment system operator can answer to an authorization request on behalf of the issuer in case none of its hosts is available in the authorization process.

In a more complex scenario, the acquirer managing the terminal at the point of service and the issuer of the card involved in the payment transaction are subscribers to the services offered by different payment system networks, which have established mutual supporting agreements. In order to guarantee the compatibility between these two different networks, two gateway nodes, GN1 and GN2 (one on each payment network), must provide the message translation between the two heterogeneous environments. Different rules concerning the definition of the transaction messages and their flow could govern the two interconnected payment networks. A possible topology of a payment network is schematized in Figure 2.4.

Figure 2.4: Payment network topology.

In this topology a national payment system operator transacting in one single currency could manage the payment system network, while an international card association transacting in multiple currencies could manage the cooperating payment system network.

2.8.1 Message structure

The acquirers and issuers must exchange messages towards completing authorization, clearing, and settlement processing. Both the acquirer and the issuer can play the role of a sender or receiver of a message. In order to facilitate the interconnection between payment system networks that cooperate, the ISO/IEC 8583:1993 standard [17] defines the format of these messages, which have the following structure:

• Message type identifier;

• Bitmap representation, which consists of one or two bitmaps of 64 bits each, giving the index of the data elements that are incorporated in the message;

• A series of data elements, in the order specified in the bitmap representation, which represents the message's body.

The standard defines the dictionary of data elements that can be used in interchange. When a bit is set in the message's bitmap representation, the corresponding data element is included in the message's body. Some data elements are of fixed length. Some other data elements are of variable length, which is specified in a fixed length prefix. The standard, however, does not preclude the use of additional data elements not specified in the dictionary, which could be required by the specific needs of payments system operators for private use.

The message type identifier is a numeric field consisting of four digits. The first digit identifies the message version number as follows :

• 0: messages defined in the previous issue of the standard referred to as the ISO 8583:1987;

• 1: messages defined in the current issue of the standard referred to as the ISO 8583:1993;

• 2 “7: reserved for ISO use;

• 8: reserved for national use;

• 9: reserved for private use.

The second digit encodes the message class as follows:

• 0 ”ISO reserved: Messages in this class are reserved for ISO use.

• 1 ”authorization: Messages in this class are used for an authorization transaction, which is an approval or guarantee of funds given by the card issuer to the acquirer. Following the authorization, the transaction amount that is approved by the issuer is not immediately billed to the cardholder's account. This is postponed until a financial message, which is sent by the acquirer to the issuer, confirms the completion of that transaction at the point of service, following the authorization.

• 2 ”financial: Messages in this class perform a financial transaction that directly bills the transaction amount to the cardholder's account.

• 3 ”file action messages: Messages in this class allow the initiation of a remote control transaction over the file system hosted in a device, like adding, changing, deleting, and replacing a record in a file or adding/deleting a file in the file system. These messages are used to perform the management of blacklists , which contain those cards that were compromised (stolen, abused through overspending, cards with compromised cryptographic material, etc.).

• 4 ”reversal/chargeback: Reversal transactions are used to undo the effect of a previous authorization or financial transaction. The acquirer triggers a reversal transaction any time the result of an authorization or financial transaction is not received from the issuer in due time, or when the cardholder voluntarily cancels the authorization or financial transaction at the point of service. Chargeback transactions also undo the effect of a previous authorization or financial transaction, but at the initiative of the issuer. The reasons that the issuer can invoke for performing a chargeback transaction include a customer dispute, an infringement of rules concerning the use of a certain type of card product on a specific terminal, the use of an expired card, or an invalid transaction.

• The messages in the classes 5 ”reconciliation, 6 ”administrative, 7 ”fee collection, and 8 ”network management are not explained in this book, but the interested reader can find their definition in the ISO 8583:1993 standard.

The third digit of the message identifier specifies the context in which the message is used. Three different situations are identified:

• The sender addresses a request message (third digit = 0) to inform the receiver that a transaction is in progress and its response is required to complete it. The receiver evaluates the request and approves or denies it, transmitting back to the sender its decision in a request response message (third digit = 1).

• The sender informs the receiver with an advice message (third digit = 2) about a certain activity that has been completed at the point of service. The receiver is not required to approve or deny the advice, but it has to elaborate an advice response message (third digit = 3), which is sent back to the sender.

• The sender informs the receiver with a notification message (third digit = 4) about a certain activity that has been performed. The notification message requires no response back from the receiver to the sender.

The fourth digit identifies the originator of a transaction and whether the current transaction is a repeat of a previous transaction.

• 0: The acquirer is the transaction originator.

• 1: The acquirer is the originator of the repeated transaction.

• 2: The issuer is the transaction originator.

• 3: The issuer is the originator of the repeated transaction.

• 4: The other role is the transaction originator.

• 5: The other role is the originator of the repeated transaction.

It is important to mention that there are some interdependencies between the last three digits of the message type identifier; for example, a reversal transaction shall use only advice messages (1420/1431 and 1430/1431) or notification messages (1440/1441).

2.8.2 Message flows

The standard also specifies the possible message flows that describe the circumstances when a message shall (or may) be sent, and the relationship between messages. In the remainder of this section we focus on several message flow examples that correspond to typical situations that appear during transaction processing. The message flows depicted in the figures below do not represent the AN, the IN, and the payment system network, but just the acquirer and the issuer.

When a terminal is connected on-line to the acquirer and the amount involved in the transaction is greater than a risk threshold limit, the terminal triggers an authorization transaction. After receiving the appropriate transaction data from the terminal (see Section 2.7), the acquirer performs an authorization phase. If the authorization does not impact the cardholder's account, a subsequent clearing stage follows.

In a dual message network, the authorization phase is performed with an authorization request message (1100). Following the evaluation of this request by IH, the guarantee of funds is approved or denied by the issuer according to the financial situation of the cardholder. The acquirer is informed about the appropriate action through an authorization request response message (1110). Following the authorization, the transaction amount that is approved by the issuer is not immediately billed to the cardholder's account. This is postponed until a separate financial message, which is sent by the acquirer to the issuer, confirms the completion of that transaction at the point of service, following the authorization. This financial message performs the clearing stage. One can distinguish between two possible approaches:

• On-line clearing: Following the reception of each authorization request response message (1110), the acquirer forms a financial advice message (1220), which bills the transaction amount to the cardholder's account. The issuer informs the acquirer about the result of this operation with a financial advice response message (1230). An overview of the on-line clearing in dual message networks is presented in Figure 2.5.

  Figure 2.5: On-line transaction in a dual message network with on-line clearing.

• Off-line clearing: Following the reception of each authorization request response message (1110), the acquirer forms a financial notification message (1240), which is stored in a clearing batch file. Periodically, this file is forwarded to the issuer, which bills each and every transaction amount of each financial notification message to the appropriate cardholder account. An overview of the off-line clearing in dual message networks for transactions approved on-line is presented in Figure 2.6.

Figure 2.6: On-line transaction in a dual message network with off-line clearing.

In a single message network, the authorization phase and the clearing phase are simultaneously performed with a financial request message (1200). Following the evaluation of this request by the IH, the guarantee of funds is approved or denied by the issuer according to the financial situation of the cardholder. The acquirer is informed about the appropriate action through a financial request response message (1210). Following the financial authorization, the transaction amount that is approved by the issuer is immediately billed to the cardholder's account. An overview of the financial authorization is given in Figure 2.7.

Figure 2.7: On-line transaction in a single message network.

When a terminal has no on-line connection or the amount involved in the transaction is below a risk threshold limit ”which is accepted by both the issuer and the acquirer ”the authorization phase can be completed locally between the card and the terminal. In this case the terminal initiates no authorization transaction, and consequently, the acquirer generates neither an authorization request message (1100) nor a financial request message (1200) for the issuer. After the terminal reports all the transactions it performed off-line during a certain period, the acquirer informs the issuer about the local completion of these transactions at the point of service, during a clearing stage. Two possibilities can be envisaged, depending on the features supported by the payment network:

• A financial advice message (1220) is issued for each transaction that is completed off-line, which allows an on-line clearing of the transactions. Each financial advice response message (1230) informs the acquirer whether the issuer accepted the transfer of liability corresponding to a transaction completed off-line. The corresponding amount involved in the locally authorized transaction is billed to the appropriate cardholder account. This is characteristic of a single message network. The corresponding message flow is schematized in Figure 2.8.

  Figure 2.8: Off-line transaction in a single message network with on-line clearing.

• In a dual message network, the acquirer firstly informs the issuer with an authorization advice message (1120) about the authorization transaction that was completed off-line at the point of service. In the authorization advice response message (1130), the issuer informs the acquirer whether it accepts or rejects the proposed transfer of financial liability. The acquirer forms a batch file, where it generates a financial notification message (1240) for each transaction accepted by the issuer. During an off-line clearing stage the batch file is forwarded to the issuer, which bills the cardholders involved. The corresponding message flow is schematized in Figure 2.9.

Figure 2.9: Off-line transaction in a dual message network with off-line clearing.