Track 1 & 2 Parser

Three encodings, one layout

Track 1 is the IATA track: %B, PAN, ^, cardholder name, ^, then YYMM expiry, a 3-digit service code and discretionary data, ending with ?. It is the only track carrying the name, and it holds 76 characters of data inside the sentinels, 79 counting them and the LRC.

Track 2 is the ABA track, and the one that actually matters: ;, PAN, =, YYMM, service code, discretionary data, ?. 37 characters of data, 40 counting the sentinels and the LRC. This is what gets sent in ISO 8583 DE 35.

Track 2 equivalent data is the chip version, EMV tag 57, or 9F6B for mag-stripe-mode contactless. Same field layout, but hex-encoded, with a D nibble standing in for the = and F nibbles padding the end when the digit count is odd. If you are working from a whole chip trace rather than the one tag, the TLV parser will find tag 57 in it and mask it.

The service code is the interesting part

Three digits, each independent. The first covers interchange and technology, and most usefully, 2 or 6 means the card has a chip. If a terminal swiped a card whose service code says 2, it should have used the chip instead. That is how fallback transactions are identified, and why they attract worse interchange and closer fraud scrutiny. The POS entry mode in DE 22 is where the fallback is declared on the message side, and the two should agree.

The second digit covers authorisation processing. The third covers PIN and service restrictions: whether a PIN is required, whether the card is good for cash, and whether it is restricted to goods and services.

Discretionary data

Issuer-defined, and opaque. It commonly carries the CVC1 or CVV (the on-stripe security code, which is not the printed CVV2), a PIN verification value or key indicator, and sometimes nothing meaningful at all. There is no general way to decode it without the issuer's specification.

A note on why you should not have this

Full track data, whether track 1, track 2 or the chip equivalent, must never be stored after authorisation. That is PCI DSS requirement 3.3.1, numbered 3.2 before v4.0, and it applies even if the data is encrypted. If you are pasting real track data in here because you found it in an application log, the log is the problem, and it is worth escalating rather than just decoding.