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.

The reversed flow

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

The customer opens their payment app; it displays a QR (often with a 1D barcode above it, so older till scanners can read something).
The cashier scans it with the till's scanner: a 2D imager, the same hardware class that reads boarding passes.
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 (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 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.