Cards Domain – Know These ISO8583-Message Details

This is some interesting information for software developers who are working in Credit cards domain. For each transaction they will receive one numeric message id of 4 digits. Many developers they are not aware about these messages. By checking the message you can tell, which transaction is happened after reading this post.

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.

Also read

Typical ISO-8583 messages in Cards Transactions

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.

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.