ISO8583 - Financial Transaction Card-Originated Messages — Interchange Message Specifications

Summary: §

• An international messaging standard for payments initiated with a financial transaction card (i.e. credit or debit card) to be facilitated safely and securely. Visa, Mastercard, etc. and other financial networks base their authorisations on the ISO 8583 standard.

What it does §

• When a cardholder uses a payment card, the electronic transaction data is exchanged throughout the network using ISO 8583 data elements, messages and code values. It details how to ‘pack and unpack’ certain data fields when processing debit and credit card transactions. The communcation process for most transactions that occur with a debit or credit card (e.g. eftpos payments, using an ATM, etc.) use ISO 8583 at some point.
• The specification allows for many card-originated financial transaction features:
  • Purchases
  • Withrdawls
  • Deposits
  • Reversals
  • Refunds
  • Balance Inquiry
  • Payments
  • Inter-account transfers

How it works: §

• The protocol transmits payment processing information via a network using TCP/IP. An ISO 8583 message can have 63 or 127 fields.
• Message structure:

  • Header: Some implementations require a message header. Commonly includes the length of the full message.

  • MTI: 4 digit numeric field which indicates the type of message (e.g. 0110). Each digit signifies important characteristics about the message:

    • 0xxx → version of ISO 8583 (e.g. 0 = 1987 version)
    • x1xx → purpose of the message (e.g. 1 = authorization message; 2 = financial message; 4 = reversal/chargeback, etc.)
    • xx1x → class/function of the message (e.g. 0 = request; 1 = response to request; 2 = advice, etc.)
    • xxx0 → message origin (who began the communication) (e.g. 0 = acquirer; 2 = issuer)

    e.g. MTI 0110 is an authorization response message stating that the actual financial transaction was originated by the acquirer.

    An MTI will completely specify what a message should do, and how it is to be transmitted around the network.

  • Bitmaps: A field/sub-field which indicates if there are other data elements somewhere else in the message. Each message always includes a primary bitmap which specifies which fields are present in the message. (i.e. which fields 1-64 are present.)

    • Explainer of the image above: The first bitmap value (70) denotes a hexadecimal (0x70) which translates to the binary 0111 0000. The first bitmap value allows us to specify which of the first 8 fields are being used. In this example the bits for field 2,3,4 are 1 = active. The next bitmap value specifies which of the next 8 fields are present. And so on.
      • bitmap values may be represented as 8 bytes of binary data or 16 hexadecimal characters.
      • a secondary bitmap can indicate which data elements 65 - 128 are present. the first bit of the primary bitmap will indicate whether the secondary bitmap is used.

  • Data Elements:

    • The data elements are the individual fields (that we specified in the bitmap section) that carry the transaction information.
      • ISO 8583:1987 has 128 data elements (primary + secondary)
      • Later ISO releases has 192 optional data elements (primary + secondary + tertiary)
    • Each data element is set out in a standard format which defines:
      • The permitted content of the field (for example, binary or numeric values ).
      • The field length (fixed or variable). If it’s variable, the length of the field is preceded by a length indicator.
      • The authorisation request is sent to the issuer and can be either approved or rejected. There can be many reasons for rejection and many aspects to consider. These are some of the possible response codes and meanings:
• How messages are processed:
  • The financial messages consist of a request/response message pair which is sent between two parties to complete the transaction.