QR Codes to Receive Money: Request and Scan to Pay
A QR code is just a URL you can point a camera at. That modest fact is why QR has become the default way to receive money across huge parts of the world: it turns a payment request into something you can print on a receipt, show on a phone, or stick on a shop window. KibiPay's request-to-pay QR does exactly this, encoding an alias and an optional amount into one scannable image.
Two flavors: request and scan
There are two directions a QR payment can flow, and it helps to name them clearly. A request-to-pay QR is generated by the person who wants to be paid; it carries their alias and, optionally, an amount and a reference. A scan-to-pay deep link is what the payer's app opens when they scan it — a pre-filled payment screen that just needs confirmation.
- Merchant shows a static QR that resolves to their handle for any amount.
- An invoice generates a dynamic QR with the exact amount and a reference baked in.
- A friend requesting a split shows a QR that pre-fills their share.
What goes inside the code
The payload is a deep link. When the payer's wallet opens it, it reads the alias to resolve, the amount if present, and any memo. Because the destination is an alias rather than a raw account, the same QR works no matter which rail ends up carrying the money — the routing decision happens after the scan, not before.
| Field | Purpose |
|---|---|
| Alias | Who to pay — resolved via the directory |
| Amount | Optional fixed value for invoices |
| Reference | Reconciliation memo or order id |
Why alias-based QR beats account-based QR
Many QR schemes embed a raw account number, which locks the code to one rail and one bank. Embedding an alias instead keeps the code durable: if the recipient changes banks or adds a wallet, the same printed QR still works because resolution happens fresh on every scan. It also means a single code can reach a payer on whichever rail is cheapest for them.
Confirming before you send
Scanning should never mean sending. A good scan-to-pay flow shows the resolved recipient name and the amount, and waits for an explicit confirm. That confirmation screen is where name-checking lives — the payer sees who the alias belongs to before any money moves, which is the same protection described in our note on confirmation of payee.
Practical gotchas
QR is friendly but not foolproof. Static codes on public surfaces can be covered by a sticker with a fraudster's code, so displaying the resolved name matters. Dynamic codes should expire. And any amount encoded in the code should be treated as a suggestion the payer confirms, never as an irreversible instruction.
Where it fits
Receive-by-QR pairs naturally with the rest of KibiPay's alias-first design: the code is a portable pointer to a directory identity, and the directory does the routing. For the broader picture of how rails differ once the scan resolves, the primer on payment rails is a helpful companion.
Static vs dynamic tradeoffs
Choosing between a static and a dynamic QR is a real design decision. A static code is cheap to produce and reusable — perfect for a shopfront or a profile — but it cannot carry a fixed amount, so the payer types one in. A dynamic code encodes a specific amount and reference, which is ideal for invoices, but it should expire and be single-use to defeat replay. Many products offer both: a durable static handle-QR for general use and freshly minted dynamic codes for individual bills. Whichever you generate, the golden rule holds — the scan resolves an alias and shows a name, and money only moves after the payer confirms. The code is an invitation to pay, never an irreversible instruction, and treating it that way keeps QR both convenient and safe.
Print it, show it, scan it — a QR is the shortest distance between "please pay me" and "done".