QR Interoperability: Same Grammar, Different Rails
Interoperability is not “any QR pays any app.” EMVCo unifies the payload grammar. Each wallet still only pays destinations it is allowed to route. That gap is where go-lives die.
Grammar versus membership
A perfect TLV string with a Thai PromptPay GUID will not pay in an app that only has Indian UPI membership. The decoder will look healthy. The app will say unsupported.
Failure cases we see
UPI URI presented to an MPM-only parser. MPM with a documentation AID. Static QR in a market that required dynamic billed QR for that MCC. Country/currency mismatch versus the merchant’s licence.
Test like a network, not like a unit test
Pick the two highest-share wallets plus one bank app in that country. Scan static and dynamic variants. Record amount-entry behavior. CRC-valid on this site is step zero, not the release sign-off.
Where to read more
National QR Schemes, UPI vs EMVCo QR, and Payment Architecture on this academy. Official scheme rules from the local operator; MPM rules from emvco.com.
App allow-lists
Some wallets only enable certain GUIDs after a business agreement. Your QR can be textbook MPM and still show “not supported.” That is interoperability as membership, not as TLV.
Dual presentation
Printing UPI URI and MPM side by side avoids forcing one grammar on all apps. Printing one code that is neither correct UPI nor correct MPM helps nobody. Decode both codes if you print two.
Version skew
An old wallet may not understand a newer additional-data sub-tag. Keep 62 conservative until your target apps are known. Interoperability is the intersection of parsers, not the union.
Evidence pack for partners
When a bank says your QR is wrong, send the raw string, decoder tag table, CRC result, and two other apps that paid. That pack ends arguments about “the picture looks fine.”
Three layers people collapse into one word
Grammar interoperability: two parsers accept the same TLV rules. Membership interoperability: a wallet is willing to pay a given GUID. Operational interoperability: the merchant file, MCC, and settlement calendar match what finance expected. A payload can be perfect at layer one and fail at layer two. Debugging only CRC will not move a membership fail.
When a bank says “your QR is not interoperable,” ask which layer they measured. Send the raw string, Decode’s tag table, CRC result, and two apps that did pay if they exist. That pack ends arguments about whether the picture looks fine.
Allow-lists, AIDs, and “not supported” screens
Many consumer apps enable QR pay only for GUIDs they contracted. Textbook MPM with a foreign or test GUID shows “not supported” or silently does nothing. That is not a TLV defect. Do not churn Tag 52 or city spelling to chase it. Change the MAI to the GUID the acquirer registered, or present a second code the inbound wallet actually contains.
Dual presentation (for example a UPI intent QR beside an MPM Bharat QR) is a product choice, not a parser trick. Each code must be valid in its own grammar. A hybrid string that is neither correct UPI nor correct MPM helps nobody. Decode both if you print both.
Version skew in Tag 62 and unreserved templates
An older wallet may not understand a newer additional-data sub-tag. Keep Tag 62 conservative until you know the target app versions. Unreserved root templates (often 80–99) are worse: if you emit one a partner does not expect, some parsers ignore it and some refuse the whole payload. Document every unreserved tag you ship.
Interoperability is the intersection of parsers, not the union. Shipping every optional field “for completeness” can reduce the set of apps that pay. Add fields when a scheme requires them, not when a blog listed them.
Cross-border tourists and inbound wallets
A tourist’s app may lack the local scheme entirely. That is not an MPM bug and not a CRC bug. Either you accept cards / another presentment, or you display a scheme the inbound wallet contains. Overlaying a second sticker without retiring the first creates scan ambiguity — customers pay whichever code the camera grabbed first.
Test with at least one inbound wallet if tourism is material. Record GUID and whether the app used an in-app camera. For normative QR rules, start at emvco.com; for in-market membership, start with the local switch document.
What this toolkit can and cannot prove
We can prove the envelope parses and that CRC matches on this site. We cannot prove that Issuer X will authorize Merchant Y. We do not operate a switch. Operator: Pankaj Kalra. Affiliation: none with EMVCo. Use the generator and decoder as a bench, then run the wallet matrix in the testing article.
Old duplicate Learn URLs for “digital payments” and “merchant QR systems” now redirect to the architecture page so reviewers do not see three synonym essays. Interoperability stays on this URL because membership and grammar are a distinct failure domain.
Partner meeting agenda
Bring raw string, tag table, CRC, two apps that paid, two that refused, market, GUID, and document version. Do not bring only a QR PNG. Meetings that start with the string end in days; meetings that start with “it looks fuzzy” end in months.
Roadmap communication
Tell merchants which wallets are in scope for launch v1. “All apps worldwide” is not a roadmap; it is a support trap. Interoperability improves by GUID registration and app updates, not by renaming Tag 59.