In a large part of the world, paying does not involve a card, a terminal or an account number. It involves pointing a phone at a square. Vietnam, the Philippines, Brazil, Colombia, Peru, Bolivia, Kenya, Tanzania, China — in all of them, a printed code is the normal way money changes hands.
If your product serves people who spend time in these markets, this is not a niche feature. It is the default payment experience, and offering everything except it is conspicuous.
What is actually in a code
Less than people assume. A payment code carries a recipient, a currency, sometimes an amount, and sometimes a reference for the payee’s own bookkeeping. It does not carry a price list, a merchant category or anything about what is being bought.
It is best thought of as an address written in a format a camera can read.
The distinction that governs everything: amount or no amount
A dynamic code is generated for one transaction and carries the total. The till calculated it, the screen displayed it, and that figure is binding. Paying anything else is refused.
A static code is printed once and used forever. It identifies who gets paid and nothing more. The amount is whatever the payer enters.
Almost every QR integration mistake comes from not knowing which kind you are holding before showing your user a number. The correct sequence is always: decode, read back what is inside, then decide what to display. Never the reverse.
Whose code can you pay
This varies by country and is worth checking per market rather than assuming.
Some accept merchant codes only — the code belongs to a registered business. Others accept personal codes too, so paying an individual works exactly like paying a shop. Vietnam and the Philippines are relaxed here. Others are not.
The practical effect is on your product copy. “Scan any code” is a promise that holds in some markets and not others, and a user who discovers the limit at the till will not remember it kindly.
Codes are not the only entry
In East Africa there is often no code at all. A merchant has a till number or a paybill number, written on a sign, and the payer types it. Any integration serving Kenya or Tanzania should accept a typed number as readily as a scanned image, because that is what people actually do.
Why this is easier to build than account payouts
Counter-intuitively, QR is the simpler product.
With an account payout you collect recipient details, validate them against local rules, and handle the failures those rules produce. With a code, the recipient details are already inside it and already correct — they were put there by the institution that issued it. There is no bank directory to maintain, no account format to police, and no name to spell correctly.
What you gain in simplicity you pay for in context: you need the user to be physically in front of a code, and you need to handle the amount rule above. That is the whole trade.
What to build first
Decode before you price. Show the user what the code says before asking them to confirm anything. Lock the amount when the code specifies one. Accept typed till numbers where the market uses them. And treat a scan failure as a normal outcome rather than an error state — codes are printed on paper, and paper gets wet, torn and photographed badly.