EMVCo QR Code Payment Standard Explained

Most articles about QR code payments treat the technical spec as a footnote. They explain what a QR payment looks like from a user's perspective, then skip directly to "scan and pay." That leaves a significant gap for anyone who actually needs to implement, certify, or audit a QR payment flow. Here is what the EMVCo QR code payment standard actually specifies: the payload structure, the two operational modes, the data objects that carry merchant and transaction information, and why the interoperability promise works at a technical level. **The EMV QR Code Specification for Payment Systems (EMV QRCPS) defines a Tag-Length-Value payload format that encodes payment credentials into a QR code in a way that any compliant reader, any bank, wallet, or payment network, can parse without proprietary SDKs.**

What EMVCo Is and Why It Owns This Space

EMVCo is the technical standards body jointly owned by American Express, Discover, JCB, Mastercard, UnionPay, and Visa. Founded in 1999 to manage the EMV chip card standard that replaced magnetic stripes globally, it turned to QR codes later: EMVCo published the first version of the EMV QR Code Specification for Payment Systems, commonly abbreviated EMV QRCPS and informally called MPQR for the merchant-presented variant, in July 2017. The Consumer-Presented Mode (CPM) specification followed in September 2018. Both were updated to v1.1 in November 2020, with the 2023 revision adding clarifications to the MPQR test case vectors. The QR code specification carries no royalties. EMVCo makes both documents publicly available on its website, which is one reason adoption happened quickly: national payment authorities could build domestic rails on the standard without licensing fees. EMVCo does not operate a payment network. It publishes the interoperability layer, the common data format that different networks agree to use so that a consumer's bank app can parse a merchant's QR regardless of which bank issued the merchant account.

The Two Modes: MPM and CPM

The EMVCo QR code payment standard defines two fundamentally different flows, each with its own specification document.

Merchant-Presented Mode (MPM)

In MPM, the merchant generates and displays the QR code. The consumer scans it with their payment app. The QR encodes merchant identity, payment destination, and optionally the transaction amount and currency. MPM supports two sub-types:

• Static MPM — A single QR code printed or displayed permanently. It identifies the merchant but does not include an amount. The consumer enters the amount in their app. Suitable for small merchants, market stalls, service providers.
• Dynamic MPM — A QR generated per transaction, typically by the point-of-sale system. Includes a specific amount, currency, and often a merchant order reference. The consumer's app pre-fills the amount. Required for unattended terminals, e-commerce, and high-volume retail.

Consumer-Presented Mode (CPM)

In CPM, the consumer generates a QR code — usually a one-time token — and displays it on their phone screen. The merchant's terminal (an optical scanner or a camera-equipped POS device) reads it. The consumer's QR contains tokenized payment credentials, not their actual card number. CPM transactions are authorized online using existing card network infrastructure. The CPM specification was built on EMV chip card security models: the token embedded in the CPM QR is analogous to the cryptogram generated by a chip during a contactless transaction. CPM is most common in supermarkets, transit systems, and fast-food chains where the merchant operates fixed scanning hardware.

Dimension	MPM	CPM
Who displays the QR	Merchant	Consumer
Who scans	Consumer (phone camera)	Merchant (POS scanner)
QR lifespan	Static (reusable) or dynamic (per-transaction)	Always dynamic (one-time token)
Amount in QR	Optional (static MPM) or included (dynamic MPM)	Not in QR — settled by network
Primary use	Retail P2M, bill payment, remittances	Supermarkets, transit, attended POS
Hardware required (merchant)	Display screen only	Optical scanner or camera
Global adoption	Dominant	Growing (APAC focus)

TLV Payload Structure — How the Data Is Encoded

Both MPM and CPM payloads use the same underlying encoding scheme: Tag-Length-Value (TLV). If you can parse TLV, you can implement, parse, or validate any EMVCo QR payload.

The Encoding Scheme

Every data element in the payload is represented as a three-part string:

• Tag — 2 numeric characters identifying the data object (e.g., 00 for Payload Format Indicator)
• Length — 2 numeric characters specifying the byte length of the value (e.g., 02 meaning 2 characters follow)
• Value — The actual content, exactly as many characters as Length specifies

A payload is a flat, left-to-right concatenation of these triplets. There is no delimiter between elements — the parser advances by reading the tag, reading the length, consuming exactly that many bytes as the value, then repeating. Example: 000201 decodes as Tag 00, Length 02, Value 01. This is the Payload Format Indicator, and 01 is the only valid value (indicating EMVCo QRCPS format version 1).

Key MPM Data Objects

Tag	Field Name	Presence	Notes
00	Payload Format Indicator	Mandatory	Always 01
01	Point of Initiation Method	Conditional	11 = static, 12 = dynamic
02-25	Merchant Account Information (international)	At least 1 required	Reserved for Visa, Mastercard, JCB, etc.
26-51	Merchant Account Information (domestic)	Optional	Domestic schemes (PromptPay, PIX, etc.)
52	Merchant Category Code	Mandatory	ISO 18245 MCC (e.g., 5411 for grocery)
53	Transaction Currency	Mandatory	ISO 4217 numeric (e.g., 764 for THB)
54	Transaction Amount	Conditional	Required for dynamic QR; omitted in static
58	Country Code	Mandatory	ISO 3166-1 alpha-2 (e.g., TH, SG)
59	Merchant Name	Mandatory	Max 25 characters
60	Merchant City	Mandatory	Max 15 characters
61	Postal Code	Optional
62	Additional Data Field Template	Optional	Nested TLV: bill number, store label, terminal ID, etc.
63	CRC	Mandatory	CRC-16/CCITT checksum of entire payload including Tag 63 header

Nested TLV Objects

Some tags contain compound objects where the value field is itself a TLV string. Tag 62 (Additional Data Field Template) is the most common example. Its sub-tags include 01 (Bill Number), 02 (Mobile Number), 03 (Store Label), 04 (Loyalty Number), 05 (Reference Label), 06 (Customer Label), 07 (Terminal Label), 08 (Purpose of Transaction), 09 (Additional Consumer Data Request). A parser must handle both flat and nested TLV correctly. A common implementation bug is treating the entire payload as flat — which works until a compound object appears, at which point the parser misreads the tag boundaries of subsequent fields.

Checksum Validation

Tag 63 is always the last element. The checksum covers the entire payload string including the 6304 prefix of Tag 63 itself, but not the 4-character checksum value that follows. The algorithm is CRC-16 with the 0x1021 polynomial (CCITT-FALSE variant). Reject payloads that fail this check. A mismatched CRC means either transmission corruption or a malformed payload. Do not proceed with parsing.

EMVCo QR vs Proprietary Payment QR Systems

Before 2017, QR payment was a patchwork of incompatible systems. Understanding the contrast clarifies exactly what the EMVCo standard solved, and what it did not.

WeChat Pay and Alipay (China)

WeChat Pay and Alipay use proprietary QR formats owned by Tencent and Ant Group respectively. Both support CPM and MPM-equivalent flows, but the payload format is not publicly specified. A scanner built for Alipay cannot parse a WeChat Pay QR, and vice versa. In China, most payment terminals support both through hardware SDKs provided by each network. Neither is EMVCo-compliant natively, though Alipay and WeChat Pay have built EMVCo-compatible adapter layers for international merchant acceptance.

UPI (India)

India's Unified Payments Interface uses a URI-based QR format: upi://pay?pa=merchant@bank&pn=MerchantName&am=100&cu=INR. This is defined by NPCI (National Payments Corporation of India), not EMVCo. The format is simpler and purpose-built for the UPI rail. BharatQR — India's card-based interoperable QR — does follow EMVCo MPM and is supported by Visa, Mastercard, and RuPay simultaneously in a single code.

PIX (Brazil)

Brazil's PIX QR is a direct implementation of EMVCo MPM v1.1, with a PIX-specific Merchant Account Information object in the domestic tag range (Tag 26). The Banco Central do Brasil mandated a single standard for all PSPs. This is the canonical success case for EMVCo adoption. A central bank mandated the spec, and genuine interoperability followed on day one. No negotiation between banks required.

PromptPay (Thailand)

PromptPay QR codes are EMVCo MPM v1.1 with a PromptPay-specific application in the domestic tag range. Thailand's Bank of Thailand published the national profile of the EMVCo spec, extending the domestic merchant account information structure to accommodate PromptPay's proxy identification system (phone number or national ID as the payment destination).

System	Format	EMVCo-based	Interoperable
PIX (Brazil)	EMVCo MPM v1.1	Yes	Yes — all Brazilian PSPs mandatory
PromptPay (Thailand)	EMVCo MPM v1.1	Yes	Yes — cross-border with PayNow (SG) since 2024
PayNow / SGQR (Singapore)	EMVCo MPM v1.1	Yes	Yes — 27+ schemes in one SGQR sticker
DuitNow (Malaysia)	EMVCo MPM v1.1	Yes	Yes — regional ASEAN corridors active
BharatQR (India)	EMVCo MPM v1.1	Yes	Yes — Visa, Mastercard, RuPay, Amex
UPI QR (India)	NPCI URI format	No	Within UPI ecosystem only
WeChat Pay (China)	Proprietary (adapter exists)	No	Within WeChat ecosystem
Alipay (China)	Proprietary (adapter exists)	No	Within Alipay ecosystem
QRIS (Indonesia)	EMVCo MPM v1.1	Yes	Yes — all Indonesian e-wallets

Country Adoption and Regional Deployment

EMVCo does not track deployment statistics centrally, but national central bank reports provide clear data on scale. Brazil: PIX processed 42 billion transactions in 2023 (Banco Central do Brasil annual report, March 2024). QR codes are the primary merchant payment initiation method. All licensed PSPs in Brazil are legally required to support PIX QR. Thailand: PromptPay had 74.8 million registered accounts as of Q3 2024 (Bank of Thailand statistical data), in a country of 70 million people. The cross-border QR link with Singapore (PayNow-PromptPay) launched in 2024, allowing consumers in either country to pay at merchants in the other by scanning local QR codes. Singapore: SGQR consolidates 27 payment schemes — including PayNow, Visa QR, Mastercard QR, WeChat Pay, and Alipay — into a single EMVCo MPM v1.1 QR sticker. This is technically accomplished by embedding multiple Merchant Account Information objects (one per scheme) into the same payload. One printed QR code covers every payment app a consumer might use. India: UPI crossed 10 billion monthly transactions in 2024 (NPCI published data). UPI QR is not native EMVCo, but NPCI has developed cross-border QR links using EMVCo-compatible formats with Singapore, France, UAE, Mauritius, and Nepal. Domestic format stays different; international corridors converge on the standard. Indonesia: Bank Indonesia mandated QRIS based on EMVCo MPM in 2020. By 2024, over 53 million merchants were registered on QRIS, the largest merchant QR deployment in Southeast Asia by count. Europe: European adoption has been slower. The European Payments Initiative (EPI) and its Wero wallet product (launched in Germany, France, and Belgium in 2024) are developing QR payment flows, but card contactless remains dominant. The UK's open banking QR-adjacent flows use different initiation mechanisms.

What This Means for Developers Building Payment-Adjacent Products

If you are building a product that reads, generates, or validates QR codes in a payment context, but you are not the payment processor, here are the practical implications.

Reading EMVCo QR Payloads

Parsing an EMVCo MPM QR payload requires a TLV parser that handles both flat and nested objects. Run the CRC check first. A mismatched CRC means the data is corrupt and any downstream parsing is meaningless. Open-source implementations exist in Java, JavaScript, Python, and Swift. The EMVCo specification documents (EMV QRCPS v1.1) are publicly available at emvco.com at no cost. If you want to inspect a live QR code payload before writing a parser, a QR code reader lets you decode the raw string and verify the TLV structure by hand.

Generating EMVCo QR Payloads

Static MPM payload generation is straightforward: assemble the mandatory tags, add payment scheme-specific Merchant Account Information objects, compute the CRC, encode the resulting string as a QR code. Dynamic MPM requires your POS system or payment gateway to inject Tag 54 (amount) and Tag 62 sub-fields (terminal ID, order reference) per transaction. The QR code format itself is standard ISO/IEC 18004 — the EMVCo specification defines the payload content, not the QR symbol encoding. A QR code generator handles the visual symbol; an EMVCo library handles the payload string.

Certification and Compliance

EMVCo offers a QR Code Type Approval Program. Products implementing MPM or CPM can obtain EMVCo type approval, which is required by some national payment authorities as a precondition for deployment. The approval process involves test vector validation against the published test case documents (EMVCo QRC Test Cases v1.0, published August 2022).

Limits of the Standard

The EMVCo QR spec is a payload format standard. It does not specify the authorization protocol used to actually move money. That happens over existing card network rails or domestic interbank networks. The QR is the initiation mechanism; clearing and settlement architecture is out of scope. If you are building a reconciliation tool or transaction monitor, you will still need to integrate with each network's API separately. The QR payload tells you who the merchant is and how much. It does not tell you whether the transaction succeeded.

When the EMVCo Standard Does Not Apply

Not every payment QR code is an EMVCo QR. Knowing the boundaries prevents wasted implementation work. If a merchant displays a QR code that encodes a plain HTTPS URL pointing to a hosted checkout page, that is not an EMVCo payload. It is a URL QR with a payment link. Most small e-commerce businesses use this pattern via Stripe, Square, or PayPal. It works, but wallet apps that parse EMVCo TLV will not recognize it. If you are implementing peer-to-peer transfers within a closed wallet ecosystem (in-app transfers between users of the same app), you do not need EMVCo. The spec targets merchant acceptance and cross-network interoperability. If you are in a market where the national payment authority has not mandated EMVCo (most of Europe, North America), your payment provider likely has a proprietary QR or does not offer QR payment initiation at all. Verify before assuming. Worth saying plainly: the EMVCo spec is genuinely well-designed for what it does. The tag range separation between international and domestic schemes is the kind of decision that looks obvious in hindsight but required real coordination across competing networks to agree on. Most payment standards committees do not produce something this usable.

How QR Nova Fits Into This Picture

QR Nova generates standard ISO/IEC 18004 QR codes, the visual symbol that encodes any string you provide. EMVCo payment QR codes use the same visual QR symbol. What distinguishes them is the TLV payload string inside. The two concerns are cleanly separable: the free QR code generator handles the visual symbol encoding, and an EMVCo payload library handles the data structure of the string inside. Dynamic QR codes as QR Nova defines them, codes where the destination URL can be updated after printing, are distinct from dynamic MPM in the EMVCo sense. EMVCo "dynamic" means a code generated per transaction with a specific amount. The terminology overlaps; the mechanics are different. For payment use cases, the EMVCo definition governs.