Parse and visualize ISO 8583 payment card transaction bitmaps.
When you swipe or tap a credit card at a terminal, the terminal doesn't send JSON to the bank. It sends a highly compressed binary message using the ISO 8583 standard.
ISO 8583 defines exactly how financial transaction messages (like authorizations, reversals, and settlements) are structured. Because this standard was created in the 1980s when bandwidth was extremely expensive, it is designed for maximum efficiency.
An ISO 8583 message can contain up to 128 different fields (e.g., Field 2 is the PAN, Field 4 is the Amount). But most transactions only use 10-15 of these fields.
Instead of sending empty fields, the message starts with a Bitmap. The bitmap is a sequence of 64 bits (8 bytes, usually represented as 16 hexadecimal characters). Each bit corresponds directly to a field. If the 4th bit is a 1, it means Field 4 is present in the message. If it's a 0, Field 4 is completely omitted.
The Primary Bitmap (always present) covers fields 1 through 64. What if the transaction needs to send Field 70?
If Field 1 (the very first bit of the Primary Bitmap) is set to 1, it acts as a flag indicating that a Secondary Bitmap immediately follows. This secondary bitmap is another 64 bits, allowing the message to indicate the presence of fields 65 through 128.
Unlike JSON, ISO 8583 is entirely strictly-ordered and length-prefixed. The parser uses the bitmap to know what to expect, and then parses the raw data stream byte-by-byte.
If the bitmap is corrupted, or if the parser calculates a bit incorrectly, it will misread the length of a field. This causes a cascading failure where every subsequent field in the entire message is read from the wrong byte offset, completely destroying the transaction data.
A typical 0200 Purchase message might have the bitmap 7224648108808000. Converted to binary, this shows that bits 2, 3, 4, 7, 11, etc. are active. This tells the Switch to expect:
In an ISO 8583 message, what is the purpose of the Bitmap?
