EMVCo QR Decoder

The encoding

EMVCo merchant-presented QR is ID-Length-Value: every element is a 2-digit ASCII identifier, a 2-digit ASCII length, then exactly that many characters of value. It resembles BER-TLV but is simpler — no multi-byte tags, no long-form lengths, and everything is printable ASCII, so a payload is human-readable if you know where the boundaries fall.

Some elements are templates whose values contain more ID-Length-Value elements: the merchant account information range (26-51), the additional data template (62), and the language template (64).

Check the CRC first

Tag 63 is a mandatory CRC-16/CCITT-FALSE over the entire payload up to and including the "6304" header itself — that inclusion is the detail most implementations get wrong. If the CRC does not match, stop: the payload has been truncated or altered, and every field after the break point is suspect.

The algorithm is polynomial 0x1021, initial value 0xFFFF, no input or output reflection, no final XOR. A quick way to check an implementation: the string 123456789 must produce 29B1.

Static versus dynamic

Tag 01 says which. 11 is static — a printed code taped to a counter, reusable, with no amount, so the consumer types one in. 12 is dynamic — generated per transaction, normally carrying an amount in tag 54, and intended for single use.

A static code carrying an amount, or a dynamic code without one, is almost always a generation bug. This decoder flags both.

Where you meet this

PIX in Brazil, PromptPay in Thailand, and most merchant QR schemes across Asia and Latin America are EMVCo MPM underneath, distinguished by the GUID in the merchant account template — for example BR.GOV.BCB.PIX. The shared spec is why one decoder handles all of them.

Note that this is the merchant-presented format. Consumer-presented QR (CPM) is a different, base64-encoded structure that wraps genuine BER-TLV — paste that into the TLV parser after decoding the base64 with the data converter.