Merchant Presented Mode (MPM)
MPM is the counter-QR model: the shop shows the code. Consumer-presented mode is the opposite. This generator builds MPM payloads.
The scan
Customer opens a wallet, scans, sees merchant name and amount behavior (typed vs locked), authenticates. Nothing in the QR bypasses issuer checks.
What must be in the code
Payable MAI, identity tags, currency, CRC. Static or dynamic POI. See payload structure.
Failure that looks like MPM but is not
A URL QR or UPI URI on the same standee is not MPM. Decode first. If there is no Tag 00, you are in another grammar.
Why shops prefer MPM
The merchant controls the printed or screen QR. Customers do not need a merchant app. That is why stickers dominate small retail. The cost is that the destination is only as trustworthy as the object the camera sees — overlays are an MPM-specific risk.
Static MPM versus screen MPM
Paper 11-codes are cheap and get dirty or replaced. A screen that refreshes a 12-code per ticket is still MPM — the shop still presents — but the payload changes. Both are merchant-presented; only Tag 01 and Tag 54 differ.
What the wallet must display
At minimum: merchant name from Tag 59 and the amount behavior implied by POI. If name is blank or a test string like EMVQRHUB, a careful wallet should warn. Our decoder shows the same fields so you can see what the wallet ought to show.
Not a payment method by itself
MPM does not move money. Cards, accounts, or wallets behind the scan still authorize. Think of MPM as a structured way to type the payee and sometimes the amount.
The physical object is part of the protocol
MPM assumes the customer’s camera sees the merchant’s code. That makes print quality, standee placement, and who is allowed to replace the sticker into security and operations concerns, not decoration. A perfect TLV string behind a dirty 2 cm print will lose to a larger overlay that encodes someone else’s MAI. Staff should treat the standee like a card terminal: known location, known serial or reprint date, and a photo of the official payload.
Screen MPM (a POS that shows a fresh QR per ticket) is still merchant-presented. The shop still aims the symbol at the customer. What changes is Tag 01 and usually Tag 54. Do not describe screen QR as consumer-presented; CPM is the opposite presentment. Mixing the names in runbooks is how night-shift cashiers display the wrong thing.
What the customer should see after a good scan
A careful wallet shows the merchant name from Tag 59, the amount behaviour implied by Tag 01 (keypad versus locked Tag 54), and the brand of the wallet itself — not a browser form asking for a card number. If Tag 59 is TEST, EMVQRHUB, or blank, the customer has no honest name to check. That is why the generator on this site is a drafting tool: you still replace cookbook names with the fascia name, abbreviated to 25 characters.
If the pay screen amount differs from the ticket, stop. Either Tag 54 is wrong, the wallet is ignoring decimals, or the cashier presented a static 11-code while speaking a billed total. Decode the exact string from that screen before you blame the issuer.
MPM does not move money
The QR is instructions: who to pay, in which currency, sometimes how much, sometimes a bill reference. Cards, accounts, or wallet balances still authorize through the same rails they always used. A CRC-valid MPM payload is not a capture, not a settlement, and not a proof of payout. When finance asks “did the QR pay,” the answer lives in the acquirer report, not in Tag 63.
This is also why overlay fraud works: the customer’s wallet happily pays whoever is in the MAI. Integrity (CRC) only proves the string was not randomly corrupted. Identity still comes from GUID allow-lists, merchant-file matching, and humans looking at Tag 59. Read the security article for controls; this page stays on presentment.
When MPM is the wrong presentment
Transit gates, some fuel pumps, and in-app checkout where the merchant already has the customer in a session often want CPM or a non-QR API. Forcing an MPM sticker into those flows creates queues and disputed amounts. Conversely, a kirana or hawker stall without a scanner almost always wants MPM: the expensive camera is already in the customer’s phone.
Our EMV studio builds MPM only. If a partner asks for a consumer QR from this site, the honest answer is no — generate CPM in the wallet product. For the official distinction, use EMVCo’s QR publications on emvco.com. We are not affiliated with EMVCo; we implement the merchant-presented envelope you can try in the browser.
Operations checklist for a live MPM counter
Before opening: confirm the printed payload still matches the stored string, scan once with a staff wallet, and check that Tag 59 matches the signboard. After a reprint: destroy or cover the old code the same day. After a POS software update: re-verify Tag 01 and Tag 54 behaviour with a 1-unit test if policy allows.
Log the payload version (a hash of the string is enough) next to the terminal ID. When a customer disputes a scan, you need to know which envelope was on the counter that hour. MPM support without payload versioning becomes a guess.
Night-shift rule
If the standee moved, was replaced, or looks newer than the ops photo, pause scans and verify the payload hash before the next sale. MPM fraud is boring until it is expensive.