QR Code Payments
A technical guide to EMVCo QR Code standards, Merchant Presented and Consumer Presented modes, and the regional QR payment ecosystems powering PIX, PromptPay, UPI, PayNow, QRIS and more.
QR Payment Transaction Flows
MPM and CPM have opposite scanning directions but use the same underlying payment rails once the transaction is initiated.
Animated flow — merchant- vs consumer-presented
The merchant displays an EMV QR code (static or dynamic); the consumer scans it with their wallet app to initiate and authorise the payment.
QR Displayed
Merchant shows an EMVCo MPM QR code.
The QR encodes merchant identifiers, and for dynamic QR the amount and a transaction reference, in EMVCo TLV format with a CRC checksum.
MPM Flow — Merchant Presented
Merchant shows QR → Customer scans → Payment initiated by customer's app
Merchant shows a static (printed) or dynamic (generated per transaction) QR code containing the EMVCo-encoded payment data.
Dynamic QR includes amount, currency, and a unique reference ID.Customer opens their banking or wallet app and scans the QR. The app parses the EMVCo TLV fields: merchant name, amount, currency, and network identifier (MAI).
App validates the CRC-16 checksum to confirm the QR was not tampered with. Invalid CRC triggers an error before any payment is attempted.
App displays merchant name (field 59), amount (field 54), and currency (field 53) for the customer to review. For static QR, customer enters the amount.
Customer authenticates via PIN, biometric, or app password and confirms the payment. Authorization happens in the customer's banking app.
Customer's bank sends a credit transfer or debit instruction through the national instant payment rail (PIX, FAST, IMPS, ITMX...) to the merchant's bank.
Merchant receives real-time notification (webhook or polling) from their payment provider confirming receipt. For dynamic QR, the reference ID links the notification to the specific transaction.
Notification latency: typically < 5 seconds on modern rails.CPM Flow — Consumer Presented
Customer shows QR → Merchant scanner reads → Payment initiated by terminal
Customer opens their payment app (Alipay, WeChat Pay, Google Pay, etc.) and navigates to the "Show QR code" or "Pay" screen.
App requests a one-time QR from the wallet server. The code embeds a tokenized payment credential and an expiry timestamp (typically 60–90 seconds). Code rotates automatically.
Merchant's POS terminal or handheld scanner reads the customer's QR. The scanned data is sent to the merchant's payment application.
POS sends the token to the acquirer / payment gateway for decoding. The gateway resolves the token to the real customer account or card credential.
Acquirer sends an authorization request to the wallet provider (or card network if CPM carries EMV token data). Includes amount, MCC, merchant ID.
Wallet provider / issuer validates the token, checks available balance or credit, and applies fraud scoring. Returns approved or declined.
Approval or decline returned to POS terminal in real time. Receipt printed. No customer action required after initial QR display.
Total transaction time: typically 2–5 seconds.MPM vs. CPM — When to Use Which
| Criteria | MPM (Merchant Presented) | CPM (Consumer Presented) |
|---|---|---|
| Who displays the QR | Merchant (printed sticker or screen) | Customer (phone app) |
| Who scans | Customer | Merchant terminal / scanner |
| Who initiates payment | Customer's banking app | Merchant's POS / acquirer |
| Hardware needed | Any screen or printer at merchant | 2D barcode scanner at merchant |
| Internet required (merchant) | Not for static QR | Yes, for real-time auth |
| Checkout speed | Slower (customer confirms) | Faster (like card swipe) |
| Fraud model | QR swapping risk | Code harvesting risk (short validity window) |
| EMV data carriage | No EMV chip data | Can carry tokenized EMV data (CPM spec) |
| Typical markets | SEA, South Asia, South America | China (dominant), some global wallets |
- Static QR: No transaction-specific data — vulnerable to sticker replacement. Mitigate with tamper-evident mounting and in-app merchant name verification.
- Dynamic QR: Short expiry (60–300 s), one-time use. Still vulnerable if displayed URL is phished.
- CPM: Consumer code must rotate automatically (every 60 s) to prevent replay. Codes should never be shareable screenshots.
- Man-in-the-Middle: Dynamic PIX uses HTTPS URLs for payload fetch — TLS pinning in the banking app is critical.
Try the QR Parser
Parse and build EMVCo QR strings with live CRC validation and field-by-field decoding.