Skip to content
barcoder

Standards/emvco-mpm

EMVCo MPM

TypeEMV QR
Completeness92%high

Overview

EMVCo Merchant-Presented Mode (EMV QRCPS-MPM) is the global TLV data-format specification that almost every modern national QR-payment standard uses inside the QR-code symbol. It was published by EMVCo in July 2017 as part of a two-spec pair (with the Consumer-Presented Mode, CPM), and is now the underlying wire format for Pix, DuitNow QR, PromptPay, QRIS, SGQR, TR QR Code, KHQR, Thai QR, VietQR, JPQR, MauCAS, GhQR, KE-QR Code, Bharat QR, NBS IPS QR, MNB QR / Qvik, UnionPay QR, BKM Express QR, and dozens of other country-scope QRs [1, 2, 3].

The spec defines what bytes go into the QR-code symbol when a merchant displays a static or dynamic QR for a customer to scan. It does not define the underlying symbology (that's qr-code — ISO/IEC 18004), the payment rail underneath (each country chooses its own — SBP, SPEI, BCB Pix, TIPS, etc.), or the consumer-side flow. What it standardises is the data envelope, so a merchant who deploys an EMVCo-MPM-compliant sticker can be read by any compliant consumer app worldwide, regardless of payment network.

History

Pre-history — pre-2017 QR fragmentation [3, sg-cro]:

Before the EMVCo spec, every national QR scheme defined its own wire format. China's alipay-qr (2011) and wechat-pay-qr (2014) used proprietary URL-token schemes. India's upi-qr (2016) used the upi://pay?... URI shape. Korea's banking apps and Japan's pre-jpqr efforts all had their own formats. Merchants in markets with multiple schemes ended up displaying multiple QR stickers — one per scheme — confusing consumers and increasing the cost of running a small business that accepted both bank-app and wallet-app payments.

July 2017 — EMVCo publishes the dual MPM + CPM specifications [3]:

  • EMV QR Code Specification for Payment Systems: Consumer-Presented Mode (EMV QRCPS-CPM), Version 1.0 — the customer's wallet displays a QR; the merchant scans it.
  • EMV QR Code Specification for Payment Systems: Merchant-Presented Mode (EMV QRCPS-MPM), Version 1.0 — the merchant displays a QR; the customer scans it with their wallet/bank app.

Both were issued under the same EMVCo umbrella that publishes the chip-card specs (EMV contact, EMV contactless, EMV 3DS), and inherit the same multi-network governance: payment-network members include American Express, Discover, JCB, Mastercard, UnionPay, and Visa.

2018 — Testing, branding, guidance [3]:

  • January 2018: EMV QR Code Self-Evaluation for CPM test cases.
  • May 2018: EMV QR Payment Mark + Reproduction Requirements published.
  • November 2018: EMV QR Code Self-Evaluation for MPM + the Merchant-Presented QR Guidance and Examples document — a non-normative companion that walks through six concrete deployment scenarios (base example, transaction-amount provided, multiple payment networks, tip/convenience fee, alternate-language merchant name, bill-pay).

Note: EMVCo "does not perform certification nor provide approvals" for QR Code implementations [3] — the self-evaluation test cases are intentionally a self-assessment tool rather than a certification gate. This is why national-QR adoption could move quickly: each country's central bank or payment switch decides locally whether to mandate EMVCo MPM and adds its own scheme-specific identifiers, without needing to wait for EMVCo certification.

November 2020 — Version 1.1 of the MPM specification [1, 3]: The current published version of the MPM spec. Refines several edge cases and clarifies the Additional Data Field template (tag 62) sub-tag definitions.

National-QR rollouts that adopted EMVCo MPM as their wire format (selected, with launch year of the EMVCo-MPM-based variant):

By 2024, EMVCo MPM is the de-facto global wire format for any national-QR rollout that wants cross-scheme interoperability; the principal exceptions are pre-spec proprietary apps (alipay-qr, wechat-pay-qr, China's unionpay-qr using its own AID-based variant) and a small number of country schemes that adopted non-EMVCo formats for political or technical reasons (upi-qr India uses the upi://pay? URI shape rather than EMVCo TLV, and sbp-universal-qr Russia uses NSPK's qr.nspk.ru URL-shape format).

Technical specification

EMVCo MPM is a TLV-encoded data-object structure rendered as plain text inside a qr-code symbol [1, 2]:

Layer Description
Operator EMVCo, LLC (industry consortium owned by American Express, Discover, JCB, Mastercard, UnionPay, Visa)
First published July 2017 (v1.0); November 2020 (v1.1 current)
Symbology carrier qr-code (ISO/IEC 18004) — typically error-correction level M, version-and-mask auto-selected
Character set UTF-8 (8-bit byte mode within QR Code)
Encoding format TLV — ID (2 ASCII digits, "00"-"99") + Length (2 ASCII digits) + Value (Length characters)
Top-level structure Sequence of data objects in canonical ID order
Integrity 4-character CRC-16/CCITT-FALSE (poly 0x1021, init 0xFFFF, no xorout, no reflection) over the entire payload up to and including the CRC tag+length ("6304"), formatted as 4 uppercase hex characters

TLV layout

Each data object is exactly: a 2-digit ID, followed by a 2-digit decimal length, followed by the value of that length. Templates (e.g. tags 26–51 and 62) contain a sequence of sub-data-objects in the same TLV format inside their value.

Top-level data objects (canonical order)

ID Name Status Notes
00 Payload Format Indicator M Always "01".
01 Point of Initiation Method O "11" static, "12" dynamic (amount in tag 54).
02–51 Merchant Account Information M (≥1) Templates. Each carries a payment scheme's identifier (a GUID or AID) + scheme-specific sub-fields. Tags 02–25 are reserved for international card networks; tags 26–51 are reserved for "other payment networks", used by national schemes (Pix at 26, DuitNow at 26, SGQR's SGQR-registry at 51, etc.).
52 Merchant Category Code M ISO 18245 4-digit MCC.
53 Transaction Currency M ISO 4217 numeric currency code, 3 digits ("840" USD, "156" CNY, "986" BRL, etc.).
54 Transaction Amount C Conditional. Present only for dynamic QRs (POI = "12"). Decimal string with . separator, ISO 4217 minor-unit precision (most currencies 2 dp; KRW/JPY/VND/CLP 0 dp; KWD/BHD/JOD 3 dp).
55 Tip or Convenience Indicator O "01", "02", or "03".
56 Value of Convenience Fee Fixed C Used when tag 55 = "02".
57 Value of Convenience Fee Percentage C Used when tag 55 = "03".
58 Country Code M ISO 3166-1 alpha-2.
59 Merchant Name M Max 25 chars (US-ASCII). Tag 64 carries alternate-language variants.
60 Merchant City M Max 15 chars.
61 Postal Code O Max 10 chars.
62 Additional Data Field O Template. Sub-tags 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).
63 CRC M Always last. 4 uppercase hex chars.
64 Merchant Information — Language Template O Carries the merchant's name + city in a non-Latin script (Chinese, Arabic, Cyrillic, etc.).
65–79 Reserved for EMVCo —
80–99 Unreserved Templates O Country-/scheme-specific use (e.g. KHQR's tag 99 NBC member-bank ID).

Merchant Account Information templates (tags 02–51)

The "MAI" templates are the point of multi-scheme support. Each template contains:

  • Sub-tag 00 — Globally Unique Identifier (GUID), one of two shapes:
    • AID-style (international card networks): hex BCD AID like A0000000651 (UPI), A000000333010101 (UnionPay), A0000007270101 (VietQR).
    • Reverse-DNS-style (national schemes): BR.GOV.BCB.PIX, SG.PAYNOW, TR.COM.BKM, MY.COM.DUITNOW, ID.CO.QRIS.WWW, etc.
  • Sub-tags 01–99 — scheme-specific fields (Pix key, PayNow proxy, IBAN, member-bank ID, transaction reference, etc.).

A single MPM QR can carry multiple MAI templates — the consumer's app picks the one its wallet supports. This is what enables sgqr's "one sticker, 24 schemes" deployment and what made duitnow-qr + [[jompay]] coexistence possible in Malaysia.

CRC algorithm

The CRC algorithm is CRC-16/CCITT-FALSE:

  • Polynomial: 0x1021
  • Initial value: 0xFFFF
  • XorOut: 0x0000
  • Input/output reflection: none
  • Computed over all data including the CRC tag (63) and length (04), but NOT the CRC value itself.
  • Emitted as 4 uppercase hex characters.

Canonical CCITT-FALSE test vector: CRC("123456789") = 0x29B1.

Use cases

EMVCo MPM is the data envelope under several distinct deployment patterns:

  • Static merchant QR — POI = "11", no amount. Printed on a sticker; customer scans, enters amount in their app. Used by hawker stalls, farm stands, and small-merchant deployments under sgqr, promptpay-qr, duitnow-qr, pix, saqr, etc.
  • Dynamic merchant QR — POI = "12", amount in tag 54. Displayed on a POS terminal or mobile app screen, regenerated per transaction. Used in supermarkets, e-commerce checkouts, and any setting where the merchant has a digital display.
  • Multi-scheme single-QR — multiple MAI templates carrying different payment-network GUIDs. The canonical example is the sgqr sticker carrying PayNow (SG.PAYNOW) + NETS (SG.COM.NETS) + the SGQR-registry record (SG.SGQR).
  • Bill-pay QR — printed on an invoice with the bill number in tag 62.01. Used by utility companies, school fee circulars, and any per-recipient invoice flow (mnb-qr Hungary explicitly mandates the bill-number sub-tag; nbs-ips-qr Serbia uses tag 32 plus a reference-credit-number sub-tag for the same purpose).
  • Tip / convenience fee — tag 55 + 56 / 57. Used by restaurants and some merchant categories in markets where convenience-fee disclosure is regulated.
  • Cross-border QR scanning — a payer with a wallet from country A scans an EMVCo-MPM sticker from country B; the wallet recognises the scheme GUID and routes the payment through the appropriate cross-border bridge (e.g. PayNow↔UPI, PromptPay↔DuitNow). The EMVCo MPM standardisation is what makes this possible without bilateral wire-format negotiations between every pair of countries.
  • Cardless ATM withdrawal — a dynamic EMVCo MPM QR on the ATM screen encodes a withdrawal request; the customer scans, authorises in their app, and the cash dispenses (vietqrcash Vietnam is the headline example).

Implementations & ecosystem

EMVCo MPM has substantial open-source library coverage in the major server languages:

Repo Language Stars Last active Kind Notes
mvallim/emv-qrcode Java 233+ 2025-08 encoder + parser The reference open-source implementation; well-maintained. Includes EMVCo PDFs in the repo for reference.
dongri/emv-qrcode Go 96+ 2024 encoder + parser Production-quality Go library.
sevenpico/EMVCoQR Swift 14+ 2024 encoder iOS implementation.
In-house bespoke encoders inside this encyclopedia TypeScript — 2026-05 encoder frontend/src/playground/encoders/{emvco-mpm,pix,duitnow-qr,promptpay-qr,qris,sgqr,khqr,tr-qr-code,nbs-ips-qr,...}.ts — the emvco-mpm encoder is the foundation, the derivatives each layer in country-specific GUIDs + sub-tag layouts.

Acquirer SDKs / commercial implementations: Mastercard, Visa, JCB, UnionPay, American Express, Discover all ship EMVCo MPM support in their merchant-acquirer SDKs. Major PSPs (Adyen, Stripe, Worldline, FIS, Fiserv) handle EMVCo MPM as a first-class payment-method type for any country where the local scheme uses it.

National-switch participation: in countries where the national QR is EMVCo-MPM-based, the central bank or designated switch typically operates a registry that issues scheme-specific GUIDs and (for some schemes) authorises merchant-specific sub-tag values. Examples: Singapore's SGQR Office at SGNIC, Saudi Payments for saqr, NAPAS for vietqr, NPCI for bharat-qr, BCB for pix, Bank Indonesia + ASPI for qris.

Fun facts

EMVCo's choice of TLV plus CRC inside a QR Code symbol is a deliberate echo of the chip-card EMV specs that EMVCo also publishes — chip-card APDUs use TLV-encoded data objects in the same shape, so payment-network engineers who already knew the EMV chip world found the QR spec immediately legible [3]. The "EMV" brand on the QR spec is not coincidence; it is intentional consistency.

The two early deployments cited in EMVCo's own 2020 talk are Singapore and Thailand [3] — both 2017-2018 multi-scheme rollouts that demonstrated the value of carrying multiple payment networks in a single QR. The Latgé talk explicitly highlights Singapore and Thailand as the proof-points that convinced subsequent national rollouts (Indonesia, Malaysia, India's NPCI for Bharat QR) to commit to the EMVCo MPM format.

EMVCo does not certify or approve QR Code implementations [3] — the self-evaluation test cases are a self-assessment tool. This is one of the structural reasons EMVCo MPM spread so quickly worldwide: no certification bottleneck. A central bank could read the public spec, implement it for the local market, and ship it without needing to negotiate with EMVCo. This is also why countries can ship slight variations of the spec (different GUID shapes, custom tag-32 templates, jurisdiction-specific sub-tag definitions) and still claim "EMVCo MPM compatible".

Tag 64 (alternate-language Merchant Information) exists specifically because non-Latin merchant names need to be present alongside an ASCII version in tag 59. A Chinese merchant whose name is "北京炸醬麵" needs tag 59 to carry an ASCII transliteration ("Beijing Zhajiangmian") and tag 64 to carry the original characters, because some legacy wallet apps cannot render UTF-8 inside tag 59. This is one of the more subtle internationalisation details in the spec.

Comparison

vs. upi-qr (India) — Different wire format. UPI uses a URI: upi://pay?pa=<vpa>&pn=<name>&am=<amount>&cu=INR. The data semantics overlap (payment address, name, amount, currency) but the encoding is completely different. UPI was published 2016, one year before EMVCo MPM; India's NPCI then issued bharat-qr (2018) as the EMVCo-MPM-compliant variant for international interoperability, while UPI-QR remains the dominant domestic format. IN.

vs. sbp-universal-qr (Russia) — Different wire format. SBP uses a URL: https://qr.nspk.ru/<QR_ID>?type=<TYPE>&bank=<MEMBER>...&crc=<CRC>. NSPK chose a URL-shape format rather than EMVCo MPM TLV; the post-2022-sanctions geopolitical context limited cross-border EMVCo participation for Russian payment infrastructure.

vs. EMV Consumer-Presented Mode ([[emvco-cpm]]) — Same EMVCo origin, opposite direction. CPM = consumer's wallet displays a QR, merchant scans it; uses a higher-density payload (often base64-encoded binary) optimised for short-range scanning at a POS terminal. MPM is far more widely deployed because the static-sticker model (no merchant POS device required) is the killer feature for emerging-market financial inclusion.

vs. swiss-qr-bill — Different wire format and scope. Swiss QR-bill uses a fixed line-separated text format inside a qr-code symbol with the special Swiss-QR cross logo. The Swiss QR-bill is invoice-presentation specific (one merchant, one bill, included in a printed payment slip), whereas EMVCo MPM is general-purpose merchant-acceptance.

vs. epc-qr (Girocode, EU) — Different wire format, similar use case. EPC QR uses an 11-field newline-separated structure for SEPA Credit Transfers in the eurozone; EMVCo MPM uses TLV. The two formats overlap in deployments where eurozone merchants accept both EPC QR (for European bank transfers) and an EMVCo MPM scheme (typically a card-network or wallet brand).

Status

Active, dominant, version 1.1 (November 2020) [1, 3].

  • De-facto global standard for new national QR-payment rollouts since 2017.
  • EMVCo MPM v1.1 is the current published version; no v2.0 announced.
  • Continued adoption: every new national QR scheme since 2020 has chosen EMVCo MPM as its wire format, with the rare exceptions noted above.
  • EMVCo's QR work continues in parallel to the chip-card and 3DS specifications under the same six-network governance.
  • No deprecation planned; the spec is treated as foundational infrastructure for the global QR-payments ecosystem.

The structural significance: EMVCo MPM is to QR payments what ISO 8583 is to card networks — the lingua franca that lets independently-built systems interoperate without bilateral negotiation. Its publication in 2017 unblocked a wave of national-QR rollouts that would otherwise have required either bespoke wire-format negotiation per country pair, or acceptance of a single closed proprietary format (alipay-qr / wechat-pay-qr) as the global default.

Sources

Deployments

No country reports mention this standard by name.

Regions / aggregations not mapped to a single country

  • Global
source · docs/standards/emvco-mpm/index.md