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 79 characters.

Track 2 is the ABA track, and the one that actually matters: ;, PAN, =, YYMM, service code, discretionary data, ?. 37 characters. 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.

The service code is the interesting part

Three digits, each independent. The first covers interchange and technology — and crucially, 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 precisely how fallback transactions are identified, and why they attract worse interchange and closer fraud scrutiny.

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 genuinely 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 — track 1, track 2, or the chip equivalent — must never be stored after authorisation. That is PCI DSS requirement 3.2, 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.