QR Payments: Request-to-Pay by Scanning a Code
QR-based payments feel modern, but the idea is simple: a QR code is a link, and in payments that link carries a request to pay. Instead of the payer typing an account number, a sort code, and an amount, the payee encodes all of it once; the payer scans and confirms. Brazil's Pix, India's UPI, and Singapore's PayNow all made QR acceptance ubiquitous for exactly this reason — it removes the error-prone data entry that kills conversion at the point of sale.
What the QR actually contains
Under the hood, a payment QR encodes a small, structured payload: the payee, the destination (account, alias, or wallet), an amount, a currency, and a reference. Schemes standardise this with formats like EMVCo's merchant-presented QR. The important property is that the QR is a request, not an authorisation — scanning it never moves money on its own; it just pre-populates the payer's app so they can approve a push payment.
How Kibipay does it
In Kibipay, a payee creates a QR request from the console (or via the API): amount, who to pay, the rail, and a reference. The platform stores the request and returns a code that encodes the pay-screen URL. The payer scans it, lands on the payment screen with every field already filled in, and confirms. The moment the payment is created, the request flips from pending to paid and links the settling payment, so the merchant sees the reconciliation without lifting a finger.
Because Kibipay is a rail-agnostic orchestration layer, the same QR flow works whether the money ultimately moves over Faster Payments, CHAPS, Bacs, or a US ACH credit — the payer's experience is identical; only the settlement underneath changes. The request carries the intended rail, but the routing engine can still reroute to a compatible rail if the first choice is unavailable.
Why merchants care
QR request-to-pay collapses three things into one scan: addressing (no mistyped account numbers), amount (no wrong totals), and reconciliation (the payment is already tied to the invoice or table number). For merchant-present acceptance — a coffee shop, a market stall, an invoice — that is the whole game: fewer failed payments, instant confirmation, and books that reconcile themselves.
Where it goes next
Dynamic QRs (a fresh code per transaction, amount baked in) suit point-of-sale; static QRs (a reusable code, payer enters the amount) suit tip jars and donations. Both are the same primitive: a signed request that resolves to a prefilled, screened, and reconciled payment. Layer Confirmation of Payee and real-time screening on top, and a scanned code becomes a fully governed payment — not just a convenient shortcut.