Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
In order for banks operating in the same association to understand each other during authorization of transactions, clearing and settlements, it is necessary to agree on the syntax and semantics of information exchange within the payment system. To this end, the ISO 8583 standard was adopted, which defines the formats and purpose of messages circulating between banks - members of the payment association.
Issuers and servicing banks can act both in the role of the sender of information and in the role of its recipient.
The ISO 8583 standard defines the following interbank message structure:
Let's take a closer look at the structure of the message type identifier. The identifier consists of four digits. The first (left) digit of the identifier defines the version of the ISO 8583 standard and today takes three values: 0 - for the first version of the 1987 standard, 1 - for the 1993 version of the standard and 2 - for the latest version of the standard that appeared in its final form in 2003. Values 3-9 of the first digit are reserved for future use (in previous versions of the standard, 8 was used for national payment systems and 9 for private systems).
The second digit of the identifier identifies the class of the message according to the following convention:
О - reserved value;
1 - authorization message. Messages of this class are used
They are used to obtain confirmation or assurance that funds associated with a specific transaction will be reimbursed by the issuer to the servicing bank. As a result of the issuance of the authorization, the issuer does not immediately debit the funds from the client's account. This occurs only upon receipt by the issuer of a financial message from the servicing bank, which confirms the completion of the operation;
2 - financial message. Messages of this class are used
to carry out a financial transaction and are "attached" to the account of the cardholder. These messages are sometimes referred to as presentments;
3 - messages for changing information in the databases of participants
payment system. Messages of this class are used to add, change and delete entries in files, as well as add / delete individual files on the hosts of the system participants. In particular, these messages are used to keep up to date the so-called stop-lists of the payment system, consisting of stolen / lost / scrambled cards;
4 - cancellation of the transaction / refusal of payment (reversal / chargeback). From
The transaction change is used by the servicing bank to reverse the result of a previous authorization or financial transaction. The service bank sends a reversal whenever it does not receive a response to the authorization request from the issuer within the specified time (timeout). Transaction cancellation is also used when a customer cancels a purchase at a point of sale.
Refusal of payment (chargeback), like canceling a transaction, is used to cancel the result of a previous authorization or financial transaction, but at the initiative of the issuer. The reason for the refusal of a payment, usually initiated by the cardholder, may be a violation of the MasterCard tor
^? 9
the new point / servicing bank of the payment system rules (for example, duplication of a transaction, the card was in the stop list at the time of the transaction, the card expired, the deadline for submitting a financial message to the issuer was violated, etc.);
5 - reconciliation check messages. Messages this
th class are used to reconcile transaction records;
6 - administrative messages. These messages are most often used
use the issuer to request additional information about the transaction from the servicing bank (retrieval request), according to which a refusal to pay (chargeback or pre-compliance) can be sent, as well as to transmit information to the sender of the message on an error that has occurred in his message. Retrieval request messages are formatted as x644 messages, where x is the version number of the ISO 8583 standard;
7 - messages intended to collect commission fees, cart
between banks of the payment system (servicing banks and issuers) in accordance with the rules of this system. These messages are not attached to client accounts. In the English version of the standard, they are called fee collection message. Fee collection messages can be transmitted from the servicing bank to the issuer, and vice versa;
8 - network management messages using
They are used to solve many problems, including establishing an inter-host connection and controlling the connection, changing keys and passwords, marking the beginning and end of a file transfer or a group of messages.
The third digit of the message type identifier specifies the requirements for the recipient of the message that the recipient must follow in order to successfully complete the transaction. The following options are considered for the requirements for the recipient of the message:
The sender sends a request message (the third digit is 0) to the recipient to inform him that a response is required from the sender with the approval of the request or its rejection in order to complete the transaction. Thus, the recipient is required to evaluate the request, make a decision on its approval or rejection, and report the result of the decision to the sender in a response message (the indicator of the response to the request is the value of the third digit, equal to 1);
О - the servicing bank is the initiator of the transaction;
1 - the servicing bank is the initiator of the repeated transaction
tion;
It should be noted that in recent years, the ISO 8583 standard has a competitor in the face of the ISO 20022 (UNIFI) standard, which has become the standard for connecting banks to the payment system in the SEPA (Single Euro Payment Area) project. The ISO 20022 standard is based on the use of XML-based messages. The language for describing the structure of messages is XML Schema (XSD). As a result, the size of interhost messages in the ISO 20022 standard increases several times, but flexibility is gained in configuring messages to transfer new data elements and simplicity of message processing on the hosts of the banks of the system.
Used notation:
Transaction participant
Mandatory message indicating the message type
Optional message indicating the type of message
Obligatory answer
Time
I
Sequence of messages
?
Intermediary Card issuer Time
Intermediary Card issuer Time
Rice. 1.4. Message flow diagram for an authorization request:
Time
I
I
I
V
Intermediary Card issuer Time
Figure 1.5. Message flow diagram for a financial transaction:
Intermediary Card issuer Time
Rice. 1.6. Message flow diagram when canceling / correcting a transaction:
Mediator
Time
I
I
I
T
Card issuer Intermediary Time
Rice. 1.7. Diagram of the message flow when a payment is canceled:
Issuers and servicing banks can act both in the role of the sender of information and in the role of its recipient.
The ISO 8583 standard defines the following interbank message structure:
- Message Type Identifier;
- bitmap (bitmap, or Bitmap Representation) of the message, having a size of 64 or 128 bits (if the size of a bitmap is 128 bits, then its first bit is 1; if the size is 64 bits, then the first bit is 0). In the VISA payment system a few years ago, a 192-bit bitmap (third bit map) was used to represent transactions on microprocessor cards to the network;
- message body, consisting of data elements, the presence of which is determined by the message bitmap. The standard operates with a certain set of data elements, the meaning of which is precisely defined. Each data element has a number assigned to it, and the bit value in the bit representation with the element number determines the presence of the data element in the message: value 1 means the element is present, 0 means its absence. Some data items are of fixed length, others are variable. In the latter case, the data item is prefixed with a fixed size, specifying the length of the data item.
Let's take a closer look at the structure of the message type identifier. The identifier consists of four digits. The first (left) digit of the identifier defines the version of the ISO 8583 standard and today takes three values: 0 - for the first version of the 1987 standard, 1 - for the 1993 version of the standard and 2 - for the latest version of the standard that appeared in its final form in 2003. Values 3-9 of the first digit are reserved for future use (in previous versions of the standard, 8 was used for national payment systems and 9 for private systems).
The second digit of the identifier identifies the class of the message according to the following convention:
О - reserved value;
1 - authorization message. Messages of this class are used
They are used to obtain confirmation or assurance that funds associated with a specific transaction will be reimbursed by the issuer to the servicing bank. As a result of the issuance of the authorization, the issuer does not immediately debit the funds from the client's account. This occurs only upon receipt by the issuer of a financial message from the servicing bank, which confirms the completion of the operation;
2 - financial message. Messages of this class are used
to carry out a financial transaction and are "attached" to the account of the cardholder. These messages are sometimes referred to as presentments;
3 - messages for changing information in the databases of participants
payment system. Messages of this class are used to add, change and delete entries in files, as well as add / delete individual files on the hosts of the system participants. In particular, these messages are used to keep up to date the so-called stop-lists of the payment system, consisting of stolen / lost / scrambled cards;
4 - cancellation of the transaction / refusal of payment (reversal / chargeback). From
The transaction change is used by the servicing bank to reverse the result of a previous authorization or financial transaction. The service bank sends a reversal whenever it does not receive a response to the authorization request from the issuer within the specified time (timeout). Transaction cancellation is also used when a customer cancels a purchase at a point of sale.
Refusal of payment (chargeback), like canceling a transaction, is used to cancel the result of a previous authorization or financial transaction, but at the initiative of the issuer. The reason for the refusal of a payment, usually initiated by the cardholder, may be a violation of the MasterCard tor
^? 9
the new point / servicing bank of the payment system rules (for example, duplication of a transaction, the card was in the stop list at the time of the transaction, the card expired, the deadline for submitting a financial message to the issuer was violated, etc.);
5 - reconciliation check messages. Messages this
th class are used to reconcile transaction records;
6 - administrative messages. These messages are most often used
use the issuer to request additional information about the transaction from the servicing bank (retrieval request), according to which a refusal to pay (chargeback or pre-compliance) can be sent, as well as to transmit information to the sender of the message on an error that has occurred in his message. Retrieval request messages are formatted as x644 messages, where x is the version number of the ISO 8583 standard;
7 - messages intended to collect commission fees, cart
between banks of the payment system (servicing banks and issuers) in accordance with the rules of this system. These messages are not attached to client accounts. In the English version of the standard, they are called fee collection message. Fee collection messages can be transmitted from the servicing bank to the issuer, and vice versa;
8 - network management messages using
They are used to solve many problems, including establishing an inter-host connection and controlling the connection, changing keys and passwords, marking the beginning and end of a file transfer or a group of messages.
The third digit of the message type identifier specifies the requirements for the recipient of the message that the recipient must follow in order to successfully complete the transaction. The following options are considered for the requirements for the recipient of the message:
The sender sends a request message (the third digit is 0) to the recipient to inform him that a response is required from the sender with the approval of the request or its rejection in order to complete the transaction. Thus, the recipient is required to evaluate the request, make a decision on its approval or rejection, and report the result of the decision to the sender in a response message (the indicator of the response to the request is the value of the third digit, equal to 1);
- the sender notifies the recipient (the third digit is equal to 2) that an operation has taken place and that the recipient is required to confirm (the third digit in the response message is 3) of the receipt of a notification on this operation (the recipient's authorization to perform the operation is not required). The messages used by the sender in this case are called advice message;
- the sender informs the recipient (the third digit of the message is 4) that an operation has taken place. In this case, the recipient is not required to confirm the fact of receiving information about this operation, nor permission to perform the operation. The message used by the sender in this case is called a notification.
О - the servicing bank is the initiator of the transaction;
1 - the servicing bank is the initiator of the repeated transaction
tion;
- 2 - the issuer is the initiator of the transaction;
- 3 - the issuer is the initiator of the repeated transaction;
- 4 - the other party is the initiator of the transaction;
- 5 - the other party is the initiator of the repeated transaction.
It should be noted that in recent years, the ISO 8583 standard has a competitor in the face of the ISO 20022 (UNIFI) standard, which has become the standard for connecting banks to the payment system in the SEPA (Single Euro Payment Area) project. The ISO 20022 standard is based on the use of XML-based messages. The language for describing the structure of messages is XML Schema (XSD). As a result, the size of interhost messages in the ISO 20022 standard increases several times, but flexibility is gained in configuring messages to transfer new data elements and simplicity of message processing on the hosts of the banks of the system.
Used notation:
Transaction participant
Mandatory message indicating the message type
Optional message indicating the type of message
Obligatory answer
Time
I
Sequence of messages
?
Intermediary Card issuer Time
Intermediary Card issuer Time
Rice. 1.4. Message flow diagram for an authorization request:
- 100/101 - authorization request / repetition of authorization request;
- 110 - response to authorization request;
- 120/121 - notification of completed authorization / repeat notification;
- 130 - response to notification of completed authorization;
- 140 - notification of completed authorization
Time
I
I
I
V
Intermediary Card issuer Time
Figure 1.5. Message flow diagram for a financial transaction:
- 200/201 - request for a financial transaction / repetition of a request for a financial transaction;
- 210 - response to a request for a financial transaction;
- 220/221 - notification of a financial transaction / repetition of a notification of a financial transaction;
- 230 - response to a notification of a financial transaction;
- 240 - financial transaction notification
Intermediary Card issuer Time
Rice. 1.6. Message flow diagram when canceling / correcting a transaction:
- 420/421 - Cancellation Notice / Repeat Cancellation Notice;
- 430 - response to the cancellation notification;
- 440 - notice of correction
Mediator
Time
I
I
I
T
Card issuer Intermediary Time
Rice. 1.7. Diagram of the message flow when a payment is canceled:
- 422/423 - failure notification / repeat failure notification;
- 432 - response to the rejection notification;
- 442 - notice of rejection
