4 QR Code Payment Models

QR payments look simple because the visible user action is only a scan. Under that square image, several payment models exist with different operational tradeoffs. The important difference is not the code format itself. It is who presents the code, who sets the amount, and how the resulting payment is matched, confirmed, and reversed.

The first model is static merchant-presented QR. The merchant prints one code and leaves it at the counter, on a table, or inside a small shop. The customer scans it, enters the amount in their banking or wallet app, and approves the payment. This model is cheap and easy to deploy, which is why it works well for micro-merchants and informal acceptance. Its weakness is reconciliation. If the customer enters the wrong amount or omits a reference, the merchant has more manual work to prove which order was paid.

The second model is dynamic merchant-presented QR. Here the point-of-sale system generates a fresh code for each basket, invoice, or bill. The amount, merchant identity, and reference are encoded into the transaction request, so the customer mostly confirms rather than types. This usually improves accounting quality because each payment already carries context for matching, refunds, and support.

The third model is consumer-presented QR. In this flow, the payer's app generates a code or token and the merchant scans it. The code may represent a wallet identity, a stored value account, or a one-time authorisation token. This model fits ecosystems where the merchant wants to recognise the customer quickly, such as transit, loyalty-linked payments, campus systems, or closed-loop wallets.

The fourth model is account-to-account or request-to-pay QR. A biller or merchant encodes bank details and a transaction reference so the scan opens a direct transfer flow in the customer's banking app. This can reduce card processing costs and works especially well in markets with fast bank rails. The operational model is different from cards, though, because settlement timing, chargeback behaviour, and dispute handling may be less familiar to merchants.

Across all four models, the real engineering questions are about controls around the scan. How is the amount verified? What reference ties the payment to an order? What happens if the network is slow, the customer closes the app, or confirmation arrives late? The QR code is only a transport layer into a broader payment system.

Fraud and tampering matter as well. Static codes can be physically replaced if merchants do not secure the display. Dynamic codes reduce that risk but depend on the checkout system being online and accurate. Consumer-presented tokens must expire correctly so screenshots or old codes cannot be replayed easily. Account-to-account flows need clear confirmation rules so merchants know when goods can be handed over.

Choosing a QR model is therefore a business and operations decision as much as a user interface decision. Static codes optimise for low setup cost. Dynamic codes optimise for cleaner reconciliation. Consumer-presented codes fit identity-heavy ecosystems. Request-to-pay QR fits markets where bank transfer rails are fast and trusted. The square image looks the same, but the surrounding system determines whether the payment flow is cheap, reliable, and supportable at scale.