QR Payment Flow
QR payment flow defines how digital payment transactions move between customers, merchants, wallets, payment gateways, and financial institutions within EMVCo QR ecosystems.
Understanding QR Payment Flow
QR payment flow describes the end-to-end process of a QR payment transaction, from QR generation and scanning to payment authorization, routing, and settlement. EMVCo QR standards help standardize these workflows across interoperable payment ecosystems.
Depending on the payment model, QR payment flows may involve merchant-presented QR codes, consumer-presented QR codes, mobile wallets, issuing banks, acquiring institutions, payment gateways, interoperability networks, and fintech payment platforms.
Standardized payment flows improve interoperability, simplify merchant integration, and enable scalable digital payment acceptance across multiple financial ecosystems.
Typical Merchant QR Payment Flow
In Merchant Presented Mode (MPM), the merchant displays a QR code and the customer scans it using a wallet or payment application.
Merchant: Displays QR → Customer: Scans QR → Wallet: Processes request → Bank: Authorizes payment → Settlement: Transfers funds
Step-by-Step QR Transaction Process
QR Code Generation: the merchant or wallet system generates a QR payload containing payment-related information.
QR Scanning: the customer or merchant scans the QR code depending on the payment model.
Payload Interpretation: the payment application parses EMVCo QR payload data and extracts transaction information.
Payment Authorization: the issuing institution validates the payment request and authorizes the transaction.
Transaction Confirmation: the payment result is communicated back to the merchant and customer.
Settlement & Reconciliation: financial settlement and reconciliation processes finalize the payment lifecycle.
Merchant Presented vs Consumer Presented Flow
Merchant Presented Mode: the merchant displays a QR code and the customer scans it using a payment application or mobile wallet. Common in retail payments; merchant displays QR; customer scans merchant QR; supports static & dynamic QR.
Consumer Presented Mode: the customer generates or displays a QR code that the merchant scans using a POS or merchant application. Wallet-generated QR; merchant scans customer QR; common in wallet ecosystems; mobile-first payment model.
Participants in QR Payment Ecosystems
Merchant: accepts QR payments and initiates merchant payment workflows.
Wallet Provider: provides payment applications for QR transaction processing.
Financial Institution: handles authorization, settlement, and transaction validation.
Benefits of Standardized QR Payment Flows
Interoperability: EMVCo standards improve compatibility across wallets, banks, and merchant ecosystems.
Low-Cost Acceptance: QR payments reduce dependency on expensive POS hardware infrastructure.
Scalable Merchant Integration: QR ecosystems simplify onboarding for merchants and fintech platforms.
Digital Payment Expansion: standardized QR systems accelerate adoption of digital payments globally.
Where CRC sits in the flow
CRC is checked in the wallet after scan and before authorization. A CRC fail never reaches the issuer. A GUID fail may reach a host that then declines. Knowing which step failed tells you whom to call.
Name the step that failed before you rewrite TLV
Typical MPM flow: present code → camera recovers payload → wallet parses TLV → CRC → display name/amount → customer authenticates → authorization → (later) settlement. CRC fails never reach the issuer. GUID fails may. Issuer declines are not generator bugs. Overlay fraud is a physical-object problem with a valid payload. If your runbook says “check the QR” for all of these, you will thrash.
Merchant-presented versus consumer-presented changes who holds the camera, not whether an issuer exists. Participants still include merchant, wallet, acquirer, issuer, and often a national switch. Standardized grammar makes parse predictable; it does not make every app a member of every GUID.
Static versus billed inside the same flow
On a static 11-code the amount is entered after parse, in the wallet. On a billed 12-code the amount arrives in Tag 54 and should be locked. Cashiers who quote a total while presenting a static sticker are inventing a hybrid flow the payload does not support. Train the presentment to match Tag 01.
Benefits of a standardized flow are debugging and multi-app parse, not guaranteed acceptance. For official QR presentment definitions, use EMVCo’s publications on emvco.com. This page maps that flow onto what you can exercise with /emv/ and /decode/.
Evidence to capture on a failed ticket
Raw payload, Decode CRC and tag table, which app, whether amount was typed or locked, time, and a photo of the physical code. Without those, “payment flow failed” is not an actionable bug. With those, you can send grammar issues to engineering and membership issues to the acquirer without a week of screenshots.
We sit before authorization. We do not see issuer responses. Architecture and interoperability articles cover those domains in more depth; this URL stays the end-to-end story for people who are new to QR pay.
Settlement is not scan
Customers experience scan-to-paid in seconds. Merchants experience settlement in hours or days. Support scripts should never promise instant payout because the QR scanned. Tag 62 bill numbers help ops tie a scan to a ticket; they do not move money. Issuer authorization messages are outside this site. We help you emit and inspect the envelope that starts the flow described in EMVCo QR specs on emvco.com.
Chargeback and dispute language
Chargebacks reference authorization and merchant descriptor, not QR module size. Train support to collect payload hash and wallet app anyway — overlay and amount-entry disputes often need them even when the card network never saw Tag 63. MPM flow documentation should link to security for physical-object fraud.
Offline and airplane mode
Parse and CRC can succeed offline; authorization cannot. Cashiers should know that “no network” is not “bad QR.” Retry when connectivity returns without reprinting unless the dynamic 12-code expired.