ISO 8583 Data Element Reference

The fields you will actually touch

DE 3, processing code. Six digits in three pairs: transaction type, from-account and to-account. 00 purchase, 01 cash withdrawal, 09 purchase with cashback, 20 refund. The account digits matter for ATMs and are usually zeros elsewhere.

DE 4, amount. Twelve digits, minor units of the DE 49 currency, zero-padded, no decimal point. See the minor units reference for why this bites.

DE 22, POS entry mode. The first two digits say how the card data was captured — 05 chip, 07 contactless chip, 81 e-commerce, 90 full mag-stripe read. Interchange depends heavily on this, so an incorrect value is expensive rather than merely wrong.

DE 39, response code. Two characters. 00 is approval; everything else is scheme-specific and the published meanings are often less useful than the processor's own documentation.

DE 55, ICC data. BER-TLV chip data — feed it to the TLV parser.

Length notation

A fixed field like n 6 is always exactly six digits. A variable field written n ..19 is LLVAR: two length digits followed by up to nineteen data digits. Three dots, as in an ...999, means LLLVAR with a three-digit length prefix. Whether those length prefixes are ASCII digits or packed BCD is, once again, an endpoint decision.

The identifiers that get confused

DE 11 (STAN) is set by the acquirer and echoed back unchanged. It is only unique within a day, per acquirer — it is a matching key, not a transaction id. DE 37 (RRN) is a twelve-character retrieval reference used to tie an authorisation to its clearing record. DE 38 is the six-character authorisation code the issuer returns. None of these is globally unique, and building a system that assumes otherwise is a well-trodden path to duplicate-detection bugs.

A warning about private fields

DE 48, 60-63 and 120-127 are reserved for private use. Two processors will use the same field number for entirely unrelated data. Never assume; always read the specification for the specific endpoint you are integrating with.