EMVCo merchant-presented QR: the spec behind PIX, QRIS and PromptPay

One spec, many flags

Most of the world's national payment QRs are the same document wearing different flags: EMVCo's QR Code Specification for Payment Systems, Merchant-Presented Mode (MPM). Brazil's PIX, Thailand's PromptPay, Indonesia's QRIS, Malaysia's DuitNow, Singapore's PayNow and SGQR, Vietnam's VietQR and India's BharatQR are all national profiles of it. Learn the skeleton once and you can read them all: see also the EMVCo QR glossary entry.

TLV: the whole grammar in one line

Every element is id (2 digits) + length (2 digits) + value:

5913Cafe Central   →  id 59, length 13, value "Cafe Central"

Concatenate elements and you have a payload. Nothing else, no delimiters, no quoting. The two-digit length is why byte-counting bugs (a multi-byte UTF-8 character where ASCII was assumed) corrupt everything downstream.

The field map

ID	Field	Notes
00	Payload format indicator	Always 01, always first
01	Point of initiation	11 static, 12 dynamic
02–25	Merchant account info	Reserved for card networks (Visa, Mastercard, …)
26–51	Merchant account templates	Where each national scheme lives
52	Merchant category code	4 digits, ISO 18245
53	Currency	ISO 4217 numeric: 986 BRL, 764 THB, 360 IDR
54	Amount	Optional, omit for payer-entered amounts
55	Tip indicator	Optional
58	Country	ISO 3166-1 alpha-2
59	Merchant name	What the payer's app displays
60	Merchant city
62	Additional data template	Reference/txid and similar
63	CRC	CRC16/CCITT-FALSE, 4 uppercase hex digits, always last

Templates: how one format holds many schemes

Ids 26–51 are containers whose values are themselves TLV. By convention sub-id 00 carries a globally unique identifier for the scheme (a reversed domain like br.gov.bcb.pix, or an application identifier like PromptPay's A000000677010111), and the remaining sub-ids carry that scheme's addressing data, a PIX key, a proxy, a bank account.

This nesting is the spec's quiet masterstroke. It lets one physical code carry several schemes side by side (which is exactly how Singapore's SGQR packs multiple payment networks into one sticker), and lets each country define its own addressing without touching the shared skeleton.

The checksum

Field 63 seals the payload with a CRC16/CCITT-FALSE (polynomial 0x1021, initial value 0xFFFF) computed over everything including the literal 6304 prefix. One altered character invalidates the code. The PIX checksum page walks through the algorithm and the classic implementation bug; the mechanics are identical across every MPM profile because they come from this spec.

Reading one yourself

Decode any payment sticker with /validate and walk the string: 000201, then fields in ascending id order, 63 last. UseQR's PIX builder constructs MPM payloads from the public specs, client-side, if you want to generate a reference payload and compare. For the reverse flow (customer shows, merchant scans) see consumer-presented mode, the companion specification.

FAQ

What is EMVCo merchant-presented mode?

The EMVCo specification for payment QR codes that a payee displays and a payer scans. It defines the tag-length-value payload structure, mandatory fields and CRC16 that national schemes like PIX, QRIS and PromptPay profile.

Which fields are mandatory in an EMVCo QR payload?

The payload format indicator (00), at least one merchant account field, merchant category code (52), currency (53), country (58), merchant name (59), merchant city (60) and the CRC (63). Amount (54) is optional.

How do different countries share one format?

Through templates: ids 26 to 51 each hold a nested TLV block identified by a scheme's unique identifier. Each national scheme defines its own template contents while the outer skeleton stays identical, and one code can carry several schemes at once.

Why do these payloads end in a CRC16?

Field 63 is a CRC16/CCITT-FALSE over the whole payload, computed including the literal 6304 prefix. It catches corruption from damaged prints or mangled copies, any single-character change invalidates the code.