Merchant QR Payment Architecture
Digital-payments and merchant-qr-systems URLs now redirect here. One architecture: the QR carries routing instructions; banks still authorize and settle. EMVCo standardizes the instruction format, not your switch.
The QR is an envelope, not a bank
When a customer scans, the wallet extracts TLV, shows amount and merchant name, then sends an authorization through the customer’s issuer. The merchant’s acquirer later settles. If the MAI GUID is wrong, that network never sees a good request. If CRC is wrong, many wallets never send a request at all.
Actors
Merchant displays MPM QR. Wallet parses tags and authenticates the user. Acquirer onboarded the merchant account inside the MAI template. A scheme or switch routes between acquirer and issuer. Issuer checks the customer’s funds or credit. Settlement files land later — not at scan time.
Why national schemes still look the same on the wire
PromptPay, SGQR, Bharat QR, and similar brands reuse MPM tags so terminals and cameras stay simple. Architecture differences live in who owns the GUID, who operates the switch, and which apps are allowed to pay. See National QR Schemes for market notes.
Static storefront versus dynamic POS
A paper 11-code is an architecture with no per-ticket backend. A 12-code from a POS is an architecture that already knows the ticket total. Mixing them without changing Tag 01/54 is how you get amount mismatches in recon.
Failure domains
Payload errors (this site): CRC, TLV, currency. Routing errors (acquirer): unknown merchant ID. Scheme errors: app not in the acceptance set. Do not debug a GUID problem by recomputing CRC.
Where EMVCo stops
emvco.com publishes QR data object rules. It does not run Indian UPI, Thai PromptPay, or Singapore SGQR. EMV QR Hub implements payload tooling only. We are not a processor and not affiliated with EMVCo.
Latency domains
Scan-to-screen is local parse plus wallet UI. Authorization is a network round trip. Settlement may be T+1. Debugging “slow QR” without saying which domain you mean wastes weeks.
Idempotency
Dynamic 12-codes should be single use at the host even if the customer scans twice. Static 11-codes are inherently multi-use; fraud monitoring then looks at velocity toward one MAI, not at QR uniqueness.
Where this site sits
We sit on the merchant device or browser, before the host. We help you emit a legal envelope. Architecture diagrams that put “EMV QR Hub” in the switch are wrong.
Redirected URLs
Old /learn/digital-payments/ and /learn/merchant-qr-systems/ addresses now 301 here so Google does not keep two synonym pages in the index.
Actors and where an envelope stops
Merchant device or browser emits TLV. Camera recovers bits. Wallet parses, checks CRC, displays Tag 59, and sends an authorization on rails that already existed. Acquirer and issuer decide. Switch and scheme may sit in between for national QR. Settlement may be T+1. The QR is an envelope, not a bank. Architecture diagrams that put “EMV QR Hub” in the switch are wrong: we sit on the merchant device before the host.
EMVCo specifies payload grammar and related testing programmes. It does not acquire your merchant. National schemes add GUIDs and branding but still look like MPM on the wire — that is why one decoder can inspect many markets without being those markets.
Latency domains and “slow QR” tickets
Scan-to-screen is local parse plus wallet UI. Authorization is a network round trip. Settlement is a batch. Debugging “slow QR” without naming the domain wastes weeks. A dim POS screen is a scan-to-screen problem. A timeout after PIN is an authorization problem. A missing payout is settlement. CRC does not belong in any of those sentences.
Idempotency: dynamic 12-codes should be single-use at the host even if scanned twice. Static 11-codes are multi-use; fraud looks at velocity toward an MAI. Mixing those in one fraud rule produces false declines or replays.
Failure domains that look the same to a cashier
Camera glare, CRC invalid, GUID not allow-listed, issuer decline, and overlay fraud all present as “app said no.” Split them with Decode (grammar), wallet error text (membership vs issuer), and a staff photo of the standee (overlay). Architecture without that split turns every incident into a generator rewrite.
Old /learn/digital-payments/ and /learn/merchant-qr-systems/ URLs 301 here so search engines do not keep synonym pages. This URL is the systems view; interoperability and testing stay on their own URLs because they are different jobs.
What to cite when you draw the diagram
For payload boxes, cite EMVCo QRCPS via emvco.com. For in-market routing, cite the scheme. For this toolkit, cite emvqrhub.com as a local encode/decode bench operated by Pankaj Kalra, not affiliated with EMVCo. Do not copy EMVCo’s site chrome into your diagram; copy the idea of naming who does what.
Static storefront versus dynamic POS is an operations choice that must show up as Tag 01 in the envelope. If the diagram says “dynamic” but the payload says 11, the diagram is fiction.
Observability hooks
Log parse result, CRC result, Tag 01, Tag 53, GUID prefix, and payload hash at the wallet boundary. Do not log full PANs if your scheme forbids it; MAI proxies may still be sensitive. Correlate with acquirer RRNs after authorization. Architecture diagrams without observability boxes are posters, not runbooks.
Disaster recovery
If print vendor ships wrong stickers, rollback means disabling scans at the till until reprint — not patching TLV in the field. Architecture should include who holds the golden payload string and who can authorize a reprint. EMV QR Hub does not hold your merchant secrets.