EMVCo QR Payload Structure
An MPM payload is one line of TLV. This page is the map of that line as our generator emits it. Official object lists are in EMVCo QRCPS on emvco.com.
Order matters
Wallets read left to right. Tag 00 opens, Tag 63 closes. Optional tags sit in between in the order the spec allows. Reordering randomly can still CRC-pass and still fail a cert suite.
Identity block
After POI you need a payable destination (26–51), who the shop is (59, 60), where (58), what MCC (52), and which currency (53). Amount (54) only when the ticket is priced in the QR.
Worked static string
00020101021126360014A000000677010111011300660000000005204581253033565802IN5910EMVQRHUB6007DELHI6304A13F is format, static POI, one MAI, MCC, INR, IN, name, city, CRC. Use it as a parse drill, never as a live merchant.
Optional additional data
Tag 62 holds bill number, mobile, store label, and similar sub-tags. Each sub-tag is TLV inside 62. If you do not need reconciliation, omit 62 rather than sending empty shells.
Generate then inspect
Build in the EMV studio, paste into Decode, compare this map. Payload decoding and the payload cookbook cover parser and samples without duplicating this structure page.
Minimum viable static sticker
00, 01=11, one MAI, 52, 53, 58, 59, 60, 63. That is enough for many micro-merchants. Adding 54 without switching to 12 is how you create amount bugs.
Minimum viable billed QR
Same as static plus 01=12 and 54. Add 62 bill number if the kitchen ticket id must survive into the acquirer report.
What not to duplicate
Do not put the same account id in two MAI templates “for luck.” Duplicate destinations are undefined. Do not put currency in Tag 59. Do not put city in Tag 58.
Byte budget
QR versions have capacity limits. Verbose merchant names plus huge 62 blobs plus logos in the image are separate problems: the payload can be fine while the pretty QR will not scan at 30 cm. Test print size.
Root order as a reading convention
A typical MPM string reads left to right as format, POI, MAI template(s), MCC, currency, (amount), country, name, city, (postal), (additional data), CRC. Wallets are stricter about presence than about whether you permutated two optional tags, but CRC depends on exact bytes, so treat order as stable. If your serializer reorders tags on every save, logs and signatures become useless.
Tag 00 first and Tag 63 last are the constraints you should treat as hard. Anything after CRC is unspecified. Anything before 00 is not MPM. Decode will show you the order it parsed; compare that to what you thought you emitted.
Minimum viable static sticker versus billed QR
Static: 00, 01=11, one MAI, 52, 53, 58, 59, 60, 63. No Tag 54. That is enough for many micro-merchants. Billed: same plus 01=12 and 54, often 62 with a bill number so kitchen tickets survive into the acquirer report. Adding 54 without switching to 12 is how you create amount bugs.
Do not put currency in Tag 59, city in Tag 58, or the account id in the merchant name. Those fields look “helpful” in a demo and become undefined for parsers. Do not duplicate the same account in two MAI templates.
Byte budget and the symbol layer
QR versions have capacity limits. Verbose names, huge 62 blobs, and a heavy logo in the image are separate problems: the payload can be legal while a 2 cm print will not scan at 30 cm. Test print size with the cameras your customers have. Error correction at the ISO layer is not a substitute for a short payload.
If you are out of budget, shorten Tag 59, drop unused 62 sub-tags, then consider QR version. Do not invent three-digit TLV lengths. See the TLV article for why 99 is the cap per value.
Worked static reading (illustrative)
000201010211…52…5303356…5802IN5910EMVQRHUB6007DELHI6304… reads as format 01, static 11, then MCC, INR, India, name EMVQRHUB, city DELHI, CRC. There is no 54, which is correct for a reusable sticker. Replace name, city, MAI, and MCC before you print; recompute CRC after every edit.
Generate in the studio, inspect in Decode, store the exact string with the print job. For the normative layout, use EMVCo QRCPS on emvco.com. We are not affiliated; we show original examples from this toolkit.
Round-trip from form to string
A form UI should serialize to TLV in one function and never let operators edit length digits by hand. If your CMS stores “merchant name” separately from “Tag 59 length,” you will eventually desync. The studio on this site keeps caps on name and city so length digits track the visible fields. Export the string, decode it, diff against the form. That round-trip is the cheapest integration test before you wire print or POS.
Logging payloads safely
Store hashes and tag summaries in logs, not necessarily full MAI in plaintext, if your scheme treats proxies as sensitive. Always store enough to reproduce CRC failures. When support pastes a string into Decode on this site, it stays local — prefer that over emailing production payloads.
POS integration boundary
Your POS should call one function: buildMpmPayload(order) → string → QR symbol. It should not let cashiers edit TLV. Tag 62 bill number should come from the order id field you already trust. If the POS cannot produce order ids, stay on static 11 until it can.
Export for print vendors
Send print vendors the ASCII string and a Decode screenshot, not only a PNG. Vendors who re-type payloads introduce length bugs. Prefer API integration that passes the string verbatim.