# EMVCo consumer-presented QR, when the customer shows the code

> In EMVCo's consumer-presented mode the roles reverse: the customer's app displays a short-lived QR containing a payment token, and the merchant's scanner reads it. It suits high-throughput checkout lanes because the till initiates the charge, and the code rotates frequently, so a captured screenshot quickly expires.

Source: https://useqr.app/docs/payments/emvco-consumer-presented-qr · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## The reversed flow

Everything else in this cluster: [PIX](/docs/payments/pix-qr-code-format), PromptPay,
[the merchant-presented spec](/docs/payments/emvco-merchant-presented-qr) they profile, has
the payee showing a code and the payer scanning. EMVCo's companion specification,
consumer-presented mode (CPM), flips it:

1. The customer opens their payment app; it displays a QR (often with a 1D barcode above
   it, so older till scanners can read something).
2. The cashier scans it with the till's scanner: a
   [2D imager](/docs/scanning/2d-imager-vs-laser-scanner), the same
   [hardware class](/docs/scanning/hardware-barcode-scanners-and-qr) that reads boarding
   passes.
3. The till pushes the charge for the basket amount against the scanned credential; the
   customer's app confirms the result.

If it feels like presenting a boarding pass, that is the right intuition: the customer
carries the credential, the infrastructure initiates the transaction.

## What is in the code: a token, not an account

The payload does not contain your account number sitting in the open. It carries a
**payment token or limited-use credential**: data the acquiring side resolves to your
account through the scheme, useless outside that resolution path. The app **refreshes the
code frequently**, typically on a timer of moments rather than minutes, and each displayed
code is intended for one presentation.

Two security consequences fall straight out:

- **A screenshot ages into uselessness.** A captured consumer code expires quickly, unlike
  a merchant-presented sticker, which is valid for years by design.
- **Never share your payment code.** A live scam pattern asks victims to "send a screenshot
  of your payment screen", with a live token, that is handing over a short window in which
  to charge you. A merchant scans your screen in front of you; nobody legitimate asks for
  the code remotely.

For the same reasons, printing a consumer-presented code is meaningless. It is dead before
the ink dries. Anything printed should be a merchant-presented payload.

## Why high-throughput lanes prefer it

At a supermarket till, merchant-presented flow has the customer aim a camera, wait for
recognition, type or confirm an amount, and authorise, tens of seconds, per customer, with
the customer's phone camera as the bottleneck. Consumer-presented flow reduces the customer's
job to holding up a screen:

- The **till initiates** with the exact basket amount, no typing, no mis-keyed totals.
- Industrial scanners decode a bright phone screen in well under a second, far faster and
  more reliably than phone cameras aim at stickers.
- The lane keeps its rhythm: scan goods, scan phone, next customer.

This is why the pattern dominates wherever queue speed is money: the supermarket checkouts
of [China's Alipay and WeChat ecosystems](/docs/payments/wechat-pay-and-alipay-qr) (which
popularised it at scale, in proprietary form), plus wallet apps in various EMVCo markets and
loyalty-and-pay schemes built on the same choreography.

## Choosing between the modes

| | Merchant-presented | Consumer-presented |
|---|---|---|
| Who displays | Payee (sticker, till screen) | Payer's app |
| Who scans | Payer's phone camera | Merchant's scanner |
| Amount entry | Payer types or code prefills | Till supplies |
| Hardware needed | None: paper works | 2D scanner at the till |
| Code lifetime | Years (static) | Moments |
| Fits | Counters, stalls, invoices, donations | High-volume lanes, transit-style gates |

The [standards comparison](/docs/payments/qr-payment-standards-compared) covers the
merchant-presented family in depth. If you are a small merchant deciding what to print, the
answer is merchant-presented: consumer-presented mode only exists where there is scanning
hardware and a till integration to drive it.

## FAQ

### What is consumer-presented mode?
The EMVCo QR flow in which the customer's app displays a short-lived code carrying a payment
token and the merchant's scanner reads it. The till initiates the charge, making it the fast
mode for checkout lanes.

### Why does the code in my payment app keep changing?
It is a rotating limited-use credential. Frequent refresh means a screenshot or shoulder-surf
captures something that expires almost immediately. That is the security model working.

### Is it safe to send someone a screenshot of my payment QR?
No. While the token lives, a screenshot is a chargeable credential, and asking for one
remotely is a known scam pattern. Present the code only to a scanner in front of you.

### Can I print a consumer-presented QR code?
No: it expires within moments of being displayed, so print is pointless. Anything printed
must be a merchant-presented payload, which is designed to stay valid indefinitely.

## Try it

- https://useqr.app/validate
- https://useqr.app/scan