ISO 8583 is the message format card payments run on: a message type, a bitmap saying which fields are present, and the fields themselves. Learning it out of order is what makes it feel hard — most people meet a chip tag before they can find the field it sits in.
This page is only an order. Every link below is an article or a tool that already exists on this site; nothing here is new material.
Two short reads. They cost four minutes and they supply the vocabulary every later article assumes you already have.
Cardholder, merchant, acquirer, issuer, plus the network. Read this first and the institution-identifier fields later on stop looking like arbitrary numbers.
~2 min readThree separate events, often treated as one. Mixing them up is where most “the money doesn’t match” questions start.
~2 min readThis is the stage that decides whether you can read a dump at all. Do it in order: the bitmap tells you which fields are present, the format notation tells you where each one ends, the encoding tells you how many bytes that is.
The two-minute map of the whole message. Everything in this stage is one of these three parts, in detail.
~2 min readThe bitmap decides which fields exist. Read it wrong and every field after it lands at the wrong offset — which is what a “garbage output” parse usually is.
~7 min readThe notation tells you how many length digits to read before the value. Miss those digits and you cut the message in the wrong place.
~3 min readThe same value takes a different number of bytes in ASCII, packed BCD and EBCDIC. Until you know which one your dump uses, every offset you count is a guess.
~8 min readYou can now split a message into fields. This stage is about turning those fields into meaning — and nobody memorises the tables, so treat these as pages you keep open.
Skim it once so you know what lives where, then keep it as the page you come back to. It is the only article here you are meant to re-open weekly.
~13 min readThe first four digits say what kind of message you are holding. Until you can read them, you cannot tell a request from a repeat of a request.
~8 min readThe MTI says what kind of message; DE3 says what kind of transaction. Two different questions, two different fields.
~2 min readThe field you read first whenever something failed, and the one people quote at you without the message around it.
~2 min readHow the card data was captured — chip, fallback, e-commerce. The same amount from the same card means different things depending on this field.
~3 min readTwo trace numbers, constantly swapped for each other. Sorting them out here saves you an argument later, when you are matching records.
~2 min readLook these up when the field actually shows up in front of you — they are not blockers for the next stage:
Everything so far was one message that behaved. Real links have retries, timeouts and amounts that come back changed.
Your checkpoint for stages 1–3: if you can follow these eight field by field, the basics held.
~10 min readThe longest read on this path, and the one you will thank yourself for: what to rule out first when the output is wrong, including the failures that never raise an error.
~14 min readThe messages that carry no money — and, in practice, the first ones you exchange when a new link is being brought up.
~7 min readWhat you owe the other side when a response never arrives — and how a retry becomes a double charge if you get it wrong.
~10 min readAn approval is not automatically an approval of your amount. Worth knowing before you write the code that assumes it is.
~7 min readRead these when you start working with a specific scheme:
DE55 is not one more fixed field — it is a container of tags, so it needs its own reading order. Do not start here: the tags below are meaningless until you can locate DE55 in the first place.
The acronym wall, one line each. Read it first so the next five articles are not four unknowns per sentence.
~2 min readThe lookup table for the whole stage — length, format and meaning for the tags you actually meet in DE55.
~13 min readThree tags that get quoted interchangeably and are not interchangeable. Sorting them out here keeps the next three articles straight.
~6 min readThe bit-level read of the tag you will be handed most often when someone asks why a chip transaction looks suspicious.
~3 min readThe card writes down its own verdict, and it is not the same field as the response code you have been reading since stage 3.
~5 min readThe question users actually ask — why this payment wanted a PIN and that one did not — answered from the message.
~8 min readDeeper cuts, once the six above are comfortable:
Authorization messages are only half the job. The other half arrives the next day as a file, in a different dictionary.
The same transaction, written down twice in two different dictionaries. This is the article that explains why your clearing record “missing” a field is not missing anything.
~5 min readNothing in a refund says which purchase it reverses. Five candidate keys, who generates each, and where each one stops matching.
~5 min readThere is no certificate at the end of this — you are done when you can take a message nobody annotated for you and say what it is, what it asks for and what came back. The full article index has everything on this site grouped by topic instead of by order, and the tools index lists all the decoders in one place.