ISO 8583: The Protocol Behind Every Card Payment

An ISO 8583 message has three parts:

1. Message Type Indicator (MTI): A 4-digit code that identifies the message. The two you will see most often: 0100 (authorization request) and 0110 (authorization response). The first digit is the ISO version (0 = 1987), the second is the message class (1 = authorization), the third is the message function (0 = request, 1 = response), and the fourth is the message origin (0 = acquirer).

2. Bitmap: A 64-bit field where each bit maps to a data element. If bit 2 is set, Field 2 (PAN) is present. If bit 39 is set, Field 39 (Response Code) is present. The bitmap is the table of contents for the message. A secondary bitmap (bit 1 set) extends the range to 128 fields.

3. Data Elements: The actual payload. Up to 128 fields carrying everything from the card number to the merchant name to the response code. Fields can be fixed-length or variable-length (prefixed with a 2 or 3 digit length indicator, called LLVAR and LLLVAR).

The fields that matter most for payment authorization and decline analysis:

Field 39 is a 2-digit alphanumeric field. 00 means approved. Everything else is some form of decline, and the specificity varies wildly.

Some codes are precise: 51 (Insufficient Funds) tells you exactly what happened. Others are deliberately vague: 05 (Do Not Honor) is used by issuers who do not want to reveal why they declined. The ISO spec defines roughly 100 possible values, but in practice you will encounter 15-20 codes regularly and a long tail of rare ones.

Field 39 is the single field that drives retry logic, dunning strategy, and churn analysis. Every page on retries.com traces back to what arrives in this field.

A transaction passes through multiple systems: Issuer → Card Network → Acquirer → Gateway → Merchant. At each hop, the response code can be translated, remapped, or stripped of context.

Examples of information loss:

• VisaNet remaps Code 59 (Suspected Fraud) to Code 05 (Do Not Honor) before it reaches the acquirer. The merchant never learns the issuer suspected fraud.
• Gateways map ISO 8583 codes to their own proprietary code systems. Stripe maps to decline_code values like generic_decline. Braintree uses processor response codes plus gateway rejection reasons.
• Aggregators like Spreedly normalize 100+ ISO codes down to approximately 19 categories. This reduces noise but also reduces signal.

The result: by the time a decline reaches your application, it may have been translated 2-3 times. The code you see is not always the code the issuer sent. This is the root cause of the "everything comes back as Code 05" problem that frustrates payments teams.

ISO 8583 is a base standard. National switches and regional networks layer proprietary extensions on top.

• Brazil: The Elo network uses its own response code set that partially overlaps with ISO but includes codes specific to Brazilian banking regulations.
• Mexico: Some Mexican banks use response codes differently from the ISO spec, particularly around codes 51 and 57.
• Europe: SCA (Strong Customer Authentication) under PSD2 introduced new decline scenarios. Response code 1A (Additional Authentication Required) and code 65 are used by European issuers to signal that 3D Secure is required. These codes did not exist when ISO 8583 was written.

If you process internationally, you cannot assume a given response code means the same thing across all issuers.

The 2-digit response code field was never designed for the nuanced information modern payment optimization requires. In 1987, a transaction either worked or it did not. There was no concept of soft vs. hard declines, retry optimization, or machine-learning-driven dunning.

This limitation is the root cause of two problems:

• The Code 05 problem. Issuers have dozens of internal decline reasons. But Field 39 only gives them 2 digits, and they have no incentive to be specific. So they default to 05.
• Decline code accuracy. The mapping between an issuer's internal decision and the 2-digit code they send is lossy by design. Two identical-looking Code 05 declines might have completely different underlying causes.

Modern alternatives exist. ISO 20022 is a richer XML/JSON-based messaging standard used by real-time payment systems. But card network authorizations still flow through ISO 8583 infrastructure, and there is no credible timeline for that to change. The installed base is too large, the switching costs too high, and the standard works well enough for the networks' purposes.