ISO 8583

A 4-digit numeric field that defines the message class, function, and origin. The first digit specifies the ISO 8583 version (e.g., 1 for 1987, 2 for 1993), the second digit indicates the message class (e.g., 1 for authorization, 4 for reversal), the third digit defines the function (e.g., 0 for request, 1 for response), and the fourth digit identifies the message origin (e.g., 0 for acquirer, 2 for issuer).

• 0100: Authorization Request from acquirer to issuer
• 0110: Authorization Response from issuer to acquirer
• 0420: Reversal Request to undo a previous transaction
• 0800: Network Management Request for echo tests and sign-on

A binary or hexadecimal encoded field that indicates which data elements are present in the message. The primary bitmap (field 1) covers data elements 1–64, while the secondary bitmap (field 1 extended) covers elements 65–128. Each bit position corresponds to a specific data element number.

• Bit 1 set to 1: Secondary bitmap is present
• Bit 2: Primary Account Number (PAN)
• Bit 4: Transaction Amount
• Bit 7: Transmission Date and Time
• Bit 11: Systems Trace Audit Number (STAN)
• Bit 32: Acquiring Institution Identification Code
• Bit 39: Response Code (e.g., 00 for approved, 05 for declined)

Each data element has a predefined format, length, and content type defined by the ISO 8583 specification. Elements can be numeric (n), alphabetic (a), alphanumeric (an), or special (s). Length encoding varies by type:

• Fixed-length fields: Length is constant and implied (e.g., MTI is always 4 digits)
• LLVAR: 1-byte length prefix followed by variable data (max 99 bytes)
• LLLVAR: 2-byte length prefix followed by variable data (max 999 bytes)
• Example: PAN (field 2) is typically LLVAR with up to 19 digits
• Example: Track 2 data (field 35) is LLLVAR containing magnetic stripe information

ISO 8583 messages traverse a defined authorization flow through the payment ecosystem. A typical purchase transaction follows this path:

1. POS Terminal → Sends 0100 Authorization Request to acquirer
2. Acquirer → Formats ISO 8583 message and routes to card network (Visa, Mastercard)
3. Card Network → Validates format and forwards to issuer
4. Issuer → Processes request, checks funds, applies fraud scoring
5. Issuer → Returns 0110 Authorization Response with response code
6. Card Network → Routes response back to acquirer
7. Acquirer → Delivers approval/decline to POS terminal

Total round-trip latency target: Typically under 2–3 seconds for the entire authorization flow.

Field 39 contains a 2-character alphanumeric response code that indicates the outcome of the transaction. Standard codes are defined by ISO 8583, though individual networks may extend them.

• 00: Approved or completed successfully
• 05: Do not honor (generic decline)
• 14: Invalid card number
• 51: Insufficient funds
• 54: Expired card
• 57: Transaction not permitted to cardholder
• 96: System malfunction

Reversal messages (MTI 0420) are critical for maintaining ledger integrity when a transaction times out or a terminal crashes after sending an authorization but before receiving the response.

While ISO 8583 defines the international standard, major card networks implement proprietary variants that extend or modify the base specification:

• ISO 8583:1987: Original widely-adopted version with 128 data elements
• ISO 8583:1993: Updated version with additional data elements and clarifications
• ISO 8583:2003: Modern version supporting chip cards (EMV) with expanded fields
• Visa Base I: Visa's implementation with network-specific fields and processing codes
• Mastercard CIS: Mastercard's variant with custom data elements for Mastercard-specific services
• EMVCo Contactless: Extensions for contactless and mobile wallet transactions

Integration challenge: Payment systems must handle multiple dialect versions simultaneously, often requiring message translation layers between different network specifications.