Paste a track 2 string and get every part named: PAN with a Luhn check, expiry, the three-digit service code decoded one digit at a time, and whatever the issuer put in the discretionary field. Both the ASCII and the BCD separator are accepted.
One string holding the card number, when it expires, what the card is allowed to do, and a block of issuer-defined data. It began as the second stripe on a magnetic card; the same layout now travels in ISO 8583 as DE35 and comes off chip cards as EMV tag 57.
The part worth reading closely is the three-digit service code. It is the card telling you which transactions it is supposed to accept.
Track 2 is one line with a separator in the middle. Everything before it is the card number; everything after it is fixed-position data followed by whatever the issuer chose to add.
| Part | Length | Content |
|---|---|---|
| PAN | up to 19 digits | The card number. Carries its own Luhn check digit |
| Separator | 1 | = in ASCII, D when packed as BCD |
| Expiry | 4 | YYMM — the card's expiry, not the transaction date |
| Service code | 3 | What the card is allowed to do. Decoded digit by digit below |
| Discretionary data | the rest | Issuer-defined. Commonly holds verification values |
The whole thing fits in 37 characters, because the physical track holds 40 including its start sentinel, end sentinel and check character. That is also the limit on DE35 in ISO 8583. If a string is longer than 37, it is not going to fit the field, and something upstream has already gone wrong.
Two characters you can ignore: a leading ; and a trailing ? plus one more character are the sentinels and the longitudinal redundancy check from the physical read. Logs often include them. This page strips them before parsing.
Three digits, each answering a different question. This is the part people look up, and the reason a card can be declined by a terminal that never contacted anyone.
| First digit | Interchange and technology |
|---|---|
1 | International interchange |
2 | International interchange, chip should be used where feasible |
5 | National interchange only, except under bilateral agreement |
6 | National interchange only, except under bilateral agreement; chip where feasible |
7 | No interchange except under bilateral agreement — private or closed loop |
9 | Test |
| Second digit | Authorisation processing |
|---|---|
0 | Normal |
2 | Contact the issuer online |
4 | Contact the issuer online, except under bilateral agreement |
| Third digit | Range of services and PIN |
|---|---|
0 | No restrictions, PIN required |
1 | No restrictions |
2 | Goods and services only, no cash |
3 | ATM only, PIN required |
4 | Cash only |
5 | Goods and services only, no cash, PIN required |
6 | No restrictions, use PIN where feasible |
7 | Goods and services only, no cash, use PIN where feasible |
So 101 — the one people look up most — is an internationally usable card, normal authorisation, no restrictions on what it buys. 201 is the same card with a chip. 221 adds “contact the issuer online”. And a service code starting with 9 is a test card, which is a useful thing to alarm on: it has no business appearing in production traffic.
Three of these digits change how a decline should be read. If the third digit requires a PIN and the terminal performed no cardholder verification, the decline is explained by the card, not by the issuer's risk engine. If the first digit says national-only and the transaction crossed a border, likewise. Reading the service code first often saves a round of escalation.
In ASCII the field separator is =. Track 2 uses a numeric code set, though, and when the data is packed as BCD — two digits to a byte — there is no code point for an equals sign. Hex D is used in its place.
Both forms describe the same card. Which one you see depends on where in the stack you took the capture, so the same transaction can show = in a gateway log and D in a host trace. Code that only accepts one of them fails on the other without saying why, which is the practical reason to know this. This page accepts both.
The layout comes from the magnetic stripe, but the name outlived the medium. A chip card carries an equivalent in EMV tag 57, with the same structure, read from the chip. Contactless taps produce it too. So finding track 2 data in a message tells you nothing about how the card was captured.
The field that does record that is DE22, the point of service entry mode. If you need to know whether a transaction was a chip read, a stripe read or a fallback, read DE22 — and if the service code says the card has a chip while DE22 says the stripe was read, that combination is the definition of a fallback.
Track 1 is a different layout: alphanumeric, longer, and it includes the cardholder name. It travels as DE45 and this page does not parse it.
The discretionary data is issuer-defined. It commonly holds a PIN verification value and a card verification value, but where each begins and how long it is comes from the issuer's own personalisation rules, not from a standard.
A generic parser that guessed at those offsets would produce confident nonsense, so this page shows the field and stops. If you need it split, the layout has to come from the issuer.
One related fact that is publicly documented and worth knowing: the verification value on the magnetic stripe and the one in the chip's track 2 equivalent are deliberately different. That is by design — it means a value copied out of a chip cannot be used to make a working stripe. And neither of them is the number printed on the back of the card, which is a separate value entirely.