Scan-to-Pay Flow

Scan to pay systems turn a QR code into a payment instruction, but the QR code itself does not move money. It carries enough information for the payer's app to identify the merchant, amount, or payment intent, and then a backend network moves funds using the wallet balance, bank rails, or card rails behind the scenes. The smooth user experience hides a chain of validation, authentication, and settlement steps.

Two common QR models

In a static QR flow, the merchant prints one reusable code. The code usually identifies the merchant account but not a specific purchase. The customer scans it, enters the amount in their wallet app, and confirms payment. Static codes are cheap to deploy, but they shift more responsibility to the user and make reconciliation harder because the merchant must match incoming payments to orders.

In a dynamic QR flow, the point of sale system generates a fresh code for a specific basket. That code can include the amount, merchant ID, currency, order reference, and an expiry time. The customer's app reads the payload, displays the exact merchant and amount, and asks for authorisation. Dynamic codes reduce input mistakes and simplify reconciliation, but require tighter integration between the payment app and the merchant system.

What happens after the scan

Once the app decodes the QR data, it validates the format and resolves the merchant record. The user then authenticates, usually with biometrics, a PIN, or device credentials. The wallet backend checks available balance or funding source, applies fraud rules, and creates a payment authorisation.

If the wallet holds stored value, the provider may debit an internal ledger immediately. If the wallet is linked to a bank account or card, the provider may initiate a transfer or card authorisation against an external rail. The merchant receives an immediate success signal for checkout, but final settlement can happen later in a batch depending on the rail.

The operational details that matter

The real system has to handle more than a happy path. QR payloads can be tampered with, so apps must verify merchant identity and reject malformed or expired codes. Networks can fail after the customer confirms but before the merchant receives acknowledgement, which creates the classic ambiguity of payment systems: did the money move or not?

This is why idempotency and transaction references matter. The app, payment gateway, and merchant system need a shared payment ID so retries do not create double charges. Merchants also need a reconciliation process because the success screen on a phone is not the same thing as settled funds in a bank account.

Why scan to pay spread so quickly

QR based payments grew fast because they are cheap at the edge. A merchant can accept digital payments without a dedicated card terminal, and a bank or wallet provider can onboard small sellers with almost no hardware cost. The backend still needs serious infrastructure for fraud checks, ledger consistency, and settlement, but the visible entry cost is low.

Scan to pay therefore succeeds when the front end is simple and the backend is disciplined. The code on the counter is only the start. The real product is the network that can authorise quickly, reconcile accurately, and recover safely when the mobile app, merchant app, or payment rail misbehaves.