ISO 8583 Parser

Parse ISO 8583 card transaction messages

1
info
PAN (card number) values are automatically masked for security (first 6 + last 4 digits shown).
Understanding ISO 8583 Card Transaction Messages
TL;DR

ISO 8583 is the international standard for card transaction messages, used every time you tap, swipe, or insert a payment card at a terminal.

What is ISO 8583?

ISO 8583 is the international standard that defines the message format for electronic payment card transactions. Every time you tap your contactless card, insert a chip, swipe a magnetic stripe, or make an online purchase, the transaction data is encoded in an ISO 8583 message that travels from the point-of-sale terminal through the acquirer, card network (Visa, Mastercard, etc.), and ultimately to the card issuer for authorization.

First published in 1987, ISO 8583 has gone through three versions: 1987, 1993, and 2003. The 1987 version remains the most widely deployed globally, although many networks have adopted elements from the later revisions. The standard is deliberately flexible — each card network (Visa, Mastercard, American Express, UnionPay) defines its own implementation specification built on top of the ISO 8583 framework.

The format is designed for high-speed, low-bandwidth communication. Unlike XML or JSON, ISO 8583 uses a compact binary/text hybrid format that can be parsed in microseconds — a critical requirement when processing tens of thousands of transactions per second.

Message Structure

Every ISO 8583 message consists of three components: the Message Type Identifier (MTI), one or two bitmaps, and the data elements themselves.

ISO 8583 Message Structure A diagram showing the three components of an ISO 8583 message: the 4-digit Message Type Identifier at the top, followed by the 64-bit bitmap grid showing which data elements are present, and then the variable-length data elements at the bottom. MTI — Message Type Identifier (4 digits) 0 1 0 0 Version=0 (1987) | Class=1 (Authorization) | Function=0 (Request) | Origin=0 (Acquirer) Primary Bitmap (64 bits — indicates which DEs are present) 1 2 3 4 5 6 7 ... 11 ... 37 41 43 ... 64 Shaded bits = Data Element present in this message Data Elements (variable length fields) DE2: PAN 4761 34** **** 0014 DE3: Proc Code 000000 DE4: Amount 000000002500 DE11: STAN 051234 DE37: RRN 000000000123 DE38: Auth Code A12345 DE41: Term ID 12345678 DE43: Merchant ACME GROCERY Each DE has a defined format: n (numeric), an (alphanumeric), ans (alpha+special), b (binary)

Message Type Identifier (MTI)

The 4-digit MTI encodes four pieces of information:

DigitMeaningValues
1stISO version0 = 1987, 1 = 1993, 2 = 2003
2ndMessage class1 = Authorization, 2 = Financial, 4 = Reversal, 8 = Network Management
3rdFunction0 = Request, 1 = Response, 2 = Advice, 3 = Advice Response
4thOrigin0 = Acquirer, 1 = Acquirer Repeat, 2 = Issuer, 3 = Issuer Repeat

Key Data Elements

DENameFormatDescription
DE2Primary Account Numbern..19The card number (PAN) — must be masked in logs
DE3Processing Coden6Transaction type: 00=purchase, 01=cash advance, 20=refund
DE4Transaction Amountn12Amount in minor units (cents) — right-justified, zero-filled
DE11System Trace Audit Numbern6Unique transaction identifier assigned by the acquirer
DE37Retrieval Reference Numberan12Key for transaction lookup and reconciliation
DE38Authorization ID Responsean6Approval code returned by the issuer
DE39Response Codean200=Approved, 05=Do Not Honor, 51=Insufficient Funds
DE41Card Acceptor Terminal IDans8Unique identifier for the POS terminal
DE43Card Acceptor Name/Locationans40Merchant name, city, state, and country

Transaction Lifecycle

A typical card payment involves at least two ISO 8583 messages:

  1. Authorization request (0100): The terminal sends a request through the acquirer to the card network and then the issuer
  2. Authorization response (0110): The issuer returns an approval (DE39 = “00”) or decline with a response code
  3. Financial advice (0220): After the cardholder completes the transaction, a financial message confirms the final amount
  4. Reversal (0420): If the transaction needs to be voided, a reversal message undoes the authorization

For an online purchase, the same flow applies — the e-commerce platform’s payment gateway generates the ISO 8583 messages on behalf of the acquirer.

Common Use Cases

  • Point-of-sale payments: Every chip, contactless, and magnetic stripe transaction at a physical terminal
  • ATM withdrawals: Cash dispensing uses 0200 (financial) messages with processing code 01
  • E-commerce transactions: Online card payments, including 3D Secure authentication flows
  • Recurring payments: Subscription billing where the merchant initiates transactions without cardholder presence
  • Refunds and reversals: 0400 (reversal) and 0200 with processing code 20 (refund) handle returns
  • Balance inquiries: Processing code 31 queries the available balance without debiting the account

Try These Examples

Valid 0100 Authorization Request Valid

An ISO 8583:1987 authorization request (MTI 0100) in key-value format with DE2 (PAN), DE3 (processing code 000000 = purchase), DE4 (amount $25.00), DE7 (transmission date/time), DE11 (STAN 051234), DE12/13 (local time/date), DE22 (POS entry mode), DE37 (retrieval reference), DE41 (terminal ID), DE43 (merchant name/location), and DE49 (currency code 840 = USD).

DE0=0100 DE2=4761340000000014 DE3=000000 DE4=000000002500 DE7=0315121530 DE11=051234 DE12=121530 DE13=0315 DE22=051 DE25=00 DE37=000000000123 DE41=12345678 DE42=000000000000001 DE43=ACME GROCERY STORE NEW YORK NY US DE49=840
Invalid Message (Unknown MTI 9999) Invalid

MTI 9999 is not a valid ISO 8583 message type identifier. The first digit must be 0 or 1 (version), the second indicates message class (1=authorization, 2=financial, 4=reversal), the third is function (0=request, 1=response, 2=advice), and the fourth is origin (0=acquirer).

DE0=9999 DE2=4761340000000014 DE3=000000 DE4=000000001000