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

> EMVCo's merchant-presented QR specification defines the tag-length-value payload behind PIX, PromptPay, QRIS, DuitNow, PayNow, VietQR and BharatQR. Every field is a two-digit id, two-digit length and value; ids 26 to 51 carry scheme-specific templates, field 54 the amount, and field 63 a CRC16 checksum closing the payload.

Source: https://useqr.app/docs/payments/emvco-merchant-presented-qr · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## 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](/docs/payments/pix-qr-code-format), Thailand's
[PromptPay](/docs/payments/promptpay-qr-thailand), Indonesia's
[QRIS](/docs/payments/qris-indonesia), Malaysia's
[DuitNow](/docs/payments/duitnow-qr-malaysia), Singapore's
[PayNow and SGQR](/docs/payments/paynow-qr-singapore), Vietnam's
[VietQR](/docs/payments/vietqr-vietnam) and India's [BharatQR](/glossary/bharatqr) are all
national profiles of it. Learn the skeleton once and you can read them all — see also the
[EMVCo QR glossary entry](/glossary/emvco-qr).

## 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](/docs/payments/pix-crc16-checksum)
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](/validate) and walk the string: `000201`, then
fields in ascending id order, `63` last. UseQR's [PIX builder](/pix) 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](/docs/payments/emvco-consumer-presented-qr), 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.

## Try it

- https://useqr.app/pix
- https://useqr.app/validate