ISO 8583 message, bitmap and MTI decoders
ISO 8583 is a standard that every processor customises, so a message that decodes cleanly against one endpoint may not against another. These tools read the 1987 structure that most traffic still resembles, and say where they lost the thread rather than guessing past it.
-
ISO 8583 Message Decoder beta
Paste a whole authorisation message and get every data element split out, interpreted and mapped to its bytes.
-
ISO 8583 MTI Decoder
Split a 4-digit message type indicator into version, class, function and origin.
-
ISO 8583 Bitmap Decoder
Turn a primary and secondary bitmap into the list of data elements present, and back again.
-
ISO 8583 Data Element Reference
All 128 data elements with formats, lengths and the ones processors love to redefine.
-
Decline Code Translator
DE 39 response codes in plain English, with what to actually do about each one.
-
POS Entry Mode Lookup
What DE 22 and tag 9F39 mean, from chip to contactless to fallback to e-commerce, and why it changes your interchange.
-
AVS & CVV Result Codes
Address and security-code check results in plain English, including which ones are fraud signals.
-
STAN vs RRN vs ARN vs Auth Code
Four identifiers, constantly confused. What each one is, who sets it, and when it is unique.
Start with the whole message
If you have a full authorisation message, paste it into the message decoder first. It reads the MTI, expands the bitmaps, walks the data elements in order and maps each one back to the bytes it came from. Everything the other tools on this page do individually, it does in one pass, and the byte offsets are what let you check its working.
The separate bitmap and MTI decoders are for when you have only that fragment, which happens more than you would expect. A colleague pastes four digits into a chat and asks what they mean, or a log line carries the bitmap and nothing else.
Where implementations diverge
The 1987 version of the standard is the common ancestor of most traffic still running, and it is what these tools read by default. What varies between endpoints is rarely the structure and almost always the encoding: whether lengths are BCD or ASCII, whether a field is packed, and which of the reserved and private elements a processor has claimed for its own use.
DE 48, DE 62 and the rest of the private range are the usual culprits. The standard reserves them, the processor fills them, and no public table can tell you with what. Where an element is commonly redefined, the data element reference says so rather than presenting one processor's use as the definition.
A message that walks off course partway through is almost always a length-prefix disagreement, not a corrupt message. The decoder reports where it lost the thread so you can see which element started the drift.
Reading the response
DE 39 carries the outcome, and the decline code translator reads it in the ISO 8583:1987 action codes every scheme started from. Bear in mind that the code reaching you may have been remapped by the acquirer or the gateway on its way, so it is the right default reading and a poor substitute for your acquirer's specification.
DE 44 carries the AVS and CVV results, and it is independent of DE 39. An issuer will approve the funds and tell you the security code was wrong in the same message, which is a decision the standard leaves to you.
DE 22 carries the POS entry mode, which decides how the transaction was read and therefore what it costs. A fallback from chip to stripe is visible here and nowhere else in the message.