EMV Payment QR Decoder

One format, five national payment schemes, and a checksum everyone reimplements

Scan a merchant's QR code in Singapore, Kuala Lumpur, Jakarta, Bangkok or Ho Chi Minh City and the thing your phone actually reads is the same in all five places: a single line of text, a few hundred characters long, holding every field as tag, length, value with no separators and no escaping. EMVCo calls it Merchant Presented Mode. PayNow, DuitNow, QRIS, PromptPay and VietQR are national schemes with different regulators, different settlement rails and different politics, and all of them carry their payload in that format — which is why one decoder can read all of them, and why a bug in a decoder is a bug in every market at once.

Reading the string

The structure is deliberately simple enough to parse with a loop and a substring. Two digits of tag, two digits of length, then exactly that many characters of value, repeated until the string runs out. The first data object is always tag 00, the payload format indicator, and the last is always tag 63, the checksum. In between sit the merchant's category code, the transaction currency as an ISO 4217 number, the amount if there is one, a two-letter country code, the merchant's name and city, and — the interesting part — one or more merchant account information templates in the range 26 to 51, each of which is itself a TLV string with a scheme identifier at its subtag 00.

That nesting is where the national schemes live, and it is not uniform. Tags 02 to 25 hold a plain value rather than a template. Tag 62 holds nested data too, and its own subtags 50 to 99 nest again. VietQR goes one level deeper than anyone else: its beneficiary organisation is a TLV string inside a TLV string inside a TLV string, with the bank's BIN and the account number as separate fields at the bottom. A decoder that tries to work out whether a value "looks like" TLV rather than applying a rule per scheme will eventually shred a merchant identifier that happens to begin with two digits, which is most of them.

The checksum, and the three ways to get it wrong

Tag 63 carries four hexadecimal digits: a CRC-16 over everything that came before. It exists to catch a code that has been damaged, truncated or retyped, and recomputing it is the only way to know that the string in front of you is the string the acquirer generated. Three details trip up implementations, and all three produce a decoder that rejects perfectly good QR codes.

First, the variant. It is CRC-16/CCITT-FALSE — polynomial 0x1021, initial value 0xFFFF, no reflection of input or output, no final XOR. The reflected variant that is also commonly called "CRC-16/CCITT" shares the polynomial and agrees on nothing else. Over the catalogue check string "123456789" the correct one gives 29B1 and the reflected one gives 2189. Second, the range. The checksum covers the payload up to and including tag 63's own tag and length — the literal characters 6304 — and stops only before the four digits themselves. Stopping four characters earlier is the single most common defect in hobby implementations. Third, the units. The length fields count characters, but the checksum is taken over bytes, and for any payload written in Latin script those are the same number, so the mistake hides until someone scans a code with a Chinese, Thai or Vietnamese merchant name on it.

A checksum that verifies tells you the payload has not changed since it was written. It tells you nothing whatsoever about whether what was written was true, or about who wrote it.

Why this matters in this region specifically

Southeast Asia adopted merchant-presented QR faster and more completely than almost anywhere else, largely because it let small merchants accept digital payment without a terminal. A hawker stall, a night-market stand or a motorbike repair shop needs a printed sticker and a bank account, not hardware. The consequence is that the security model rests on a sticker: the payee identifier is printed on a piece of paper stuck to a wall, and swapping that paper is the entire attack. That risk is well known, and it is worth being precise about what a decoder can and cannot do about it. It can tell you which scheme a code belongs to, which country registered the identifier, what account proxy it will pay, whether an amount is fixed or open, and whether the string is internally consistent. It cannot tell you that the sticker belongs to the shop you are standing in.

The cross-border linkages make reading the payload more useful, not less. Several ASEAN schemes now accept each other's codes, so a payload generated under one country's rules is routinely read by a wallet built for another's. When something goes wrong in that path — an amount that a wallet refuses, a merchant name that arrives truncated, a code that one app reads and another rejects — the answer is almost always visible in the fields. A merchant name over the 25-character limit gets cut. An amount written with a thousands separator is not a valid amount. A dynamic code with no amount in it will be read as one the payer must fill in. None of that is diagnosable by looking at the picture.

What this tool does not do

It does not use your camera directly — photograph the code and give it the picture, which it reads in this page without uploading it. It does not generate codes, and deliberately so: a tool that produced a payment QR carrying somebody else's merchant name would be a forgery kit. It does not contact the scheme, so it cannot tell you whether an account proxy is real, registered or active; nothing about the identifier's format proves anything about the payee. And its scheme registry is a list of identifiers that have been published — when an identifier is not in it, the tool says so and infers only what the string's own shape supports, which for a reverse-domain identifier is the country that registered it, and nothing more.