A Sticker Beats a Terminal: What a QR Payment Actually Is

Part I · Why an Alternative Exists at All (Chapters 1–2) Builds on: Chapter 1 (acceptance cost, the acceptance gap, the costs on both sides of a two-sided market) New concepts in this chapter: merchant-presented QR, consumer-presented QR, static and dynamic codes, EMVCo's QR specification, sticker-swap fraud, form factor versus rail

1. The Question the Previous Chapter Left Open¶

What the previous chapter left behind is a gap.

Cards run on three assumptions, and the merchant side is the expensive one. What is expensive is not the plastic shell of the POS terminal but the process that turns a merchant into a "verified merchant": sign an acquiring agreement, pass due diligence, get a merchant ID, accept a settlement cycle, take on chargeback liability. Hardware gets cheaper. That process does not. So the vegetable stall doing two hundred thousand rupiah a day will never see the salesperson who installs the terminal.

The previous chapter ended on two questions: what does a way to get paid look like when it needs no terminal and no merchant verification, and where does it move the cost to?

This chapter answers both. Conclusion first: the thing is a pattern printed on paper. It pushes merchant-side hardware cost down to the price of printing a sheet, and the price is that the cost moves to three new places — the consumer's phone, a central ledger that must never go offline, and a new category of fraud that lands on the payer.

Cost did not disappear. It changed location, and it changed who carries it. Following that cost is the spine of this chapter.

2. It Has Existed Since 1994, and Had Nothing to Do With Payments¶

The QR code is not an invention of the payments industry.

In 1994, Masahiro Hara and his team at Japan's Denso Wave built it. The problem was concrete: car parts moving down a production line, barcodes that could not hold enough information, and workers who had to angle each part just so to get a read. They wanted a pattern that held more data and could be read from any orientation.

That origin left two consequences, both of which matter enormously for payments.

The first is error correction. A QR code carries redundancy in the encoding itself, so a pattern with a chunk missing, a smear of dirt, or a crooked print can still be reconstructed. Parts on a line get knocked about and get oily, so it had to stay readable. Ported into payments, that becomes: a sticker on the plank of a vegetable stall, rained on, with one corner rubbed off by a sleeve, still scans. An encoding designed for dirty parts turns out to be the only encoding usable as a street-side way to get paid.

The second consequence matters more, and has nothing to do with technology.

Denso Wave held patents on the QR code, and the standardisation work ran from the late 1990s into the early 2000s, ending as ISO/IEC 18004. But Denso Wave charged no fee for using the standard. Anyone can generate a QR code, write a scanner, print it on anything, with nobody to ask and nothing to pay.

Compare NFC — the near-field communication you use when you tap a card or phone on a reader. NFC can be very cheap on the consumer side too; the problem is the merchant side. To accept NFC, a merchant needs a real reader, and that machine has to be certified, has to carry a security module, has to be upgraded whenever the card network's specification moves — and along that chain the chip maker, the device maker, the certification body, and the licensor each take a cut.

The first reason a QR code can cover a whole country is not that it is technically good. It is that there is no toll gate. Any technology with somebody collecting money in the middle spreads at a rate decided by that somebody's commercial judgement. With nobody collecting, it spreads at a rate decided by demand.

3. Two Kinds of Code: Who Shows It, Who Scans It¶

Now the thing that gets confused most. Everyday language calls all of it "QR payment," but it is two things pointing in opposite directions. Miss this and none of the differences between the next three countries will make sense.

Merchant-presented QR

The merchant puts the code out, and the payer scans it with his own phone.

What the code holds is the merchant's identity: his ID inside some payment institution or clearing system, possibly along with his name and the amount to be collected. The payer scans, his phone shows "pay Such-and-Such Shop," he confirms and enters a PIN or a fingerprint, and the payment instruction goes out from the payer's app.

The sticker on the vegetable stall's wall is this kind.

Consumer-presented QR

The reverse. The payer brings up a code on a screen in his own app, and the merchant scans it with a device.

What the code holds is a payment credential pointing at the payer's account, usually valid for only a few dozen seconds and dead after that. The merchant scans it, feeds it into his own acquiring chain, and the merchant side raises the debit request.

The scan gun by the counter at a convenience store is doing this.

Different directions, different prices. Merchant-presented QR pushes connectivity, compute, and interface entirely onto the payer. Consumer-presented QR leaves all three with the merchant, and buys checkout speed in return — a scan gun reads a screen instantly, with no customer bending over a phone typing an amount. So the large chains prefer consumer-presented QR, and long-tail merchants can only use merchant-presented QR.

One note on direction: on the merchant-presented path, the money is pushed out by the payer, not pulled by the merchant. Payment Systems has already covered the difference between push and pull, and this course does not repeat it. The conclusion is all you need: a merchant-presented QR payment is a push payment, and the merchant has no ability to raise a debit against the payer's account. That sentence gets used again when we come to fraud and to dispute handling.

4. Static and Dynamic: The Only Difference Is Whether the Amount Is In It¶

Merchant-presented QR needs one more split inside it.

Static code: the code holds only the merchant ID, no amount. The payer scans and types in what he owes. Print it once, stick it on a wall, use it for years.

Dynamic code: the code carries the amount, and possibly an order number. The till system generates one fresh for each transaction and it dies after use.

Look at the bottom two rows. The static code removes every piece of merchant equipment, and the price is that it hands both "entering the amount" and "the authenticity of the code" to the payer. Each of those prices gets its own section below.

5. Which One Crosses the Acceptance Gap¶

Now the previous chapter's first question can be answered. What actually fills the acceptance gap is the merchant-presented static code.

Run it through the previous chapter's framework. To accept an electronic payment, a merchant's cost splits in two: hardware cost and institutional cost.

On hardware cost the answer is almost absurdly clean: the price of printing a sheet of paper.

Not a cheaper machine — no machine. The stallholder needs no card reader, no communications module, no receipt rolls, no maintenance, and nobody coming out to install anything. What he needs fits in an apron pocket, and if he loses it he prints another. The previous chapter said a fixed cost meeting a tiny volume becomes absurd. This fixed cost is now near zero, and spreading it across twenty thousand a day or five million a day gives the same answer: zero.

Institutional cost has to be stated carefully, because the previous chapter said it is the hard part. It did not go to zero.

The merchant still has to open a receiving account at a licensed institution — a payment institution or a bank. That institution still has to check who he is, look at what business he runs, give him an ID, decide how fast to settle to him, and decide whether the money carries risk. Not one of those steps was dropped.

What changed is who does the process, how long it takes, and how much labour it eats:

• It used to take a salesperson making a trip. Now the merchant walks through it himself in a phone app: photograph the ID document, photograph the shopfront, fill in a few fields, submit. Labour cost falls from "one site visit plus one installation" to "one self-service submission plus one back-office review."
• Review standards used to be set against the outlay for a machine, so a merchant that small was not worth reviewing. Now micro merchants go through a simplified onboarding: small limits, low caps, and risk absorbed by that institution inside its own ledger. Reviewing one is unprofitable; reviewing ten thousand is just servers running.
• Merchants used to carry chargeback liability, the heaviest part of due diligence — what an acquirer fears is a merchant vanishing and leaving a pile of refunds behind. A merchant-presented QR payment is a push payment, with none of the cardholder-initiated chargebacks cards have, so the merchant side's risk exposure has a completely different shape and a whole category of review questions falls away.

Institutional cost did not go to zero. It went from "a per-merchant sales cost" to "a software cost incurred once, with a marginal cost near zero after that." That is the real reason the gap got crossed. The previous chapter said institutional cost does not fall when hardware gets cheaper — correct. It fell only once the process was done a different way, and what fell was the labour, not the review.

6. Where the Cost Went¶

The previous chapter's second question: cost does not disappear, it moves — so where to? Three places.

First: the payer's phone and data

The merchant needs no card reader because the card reader is already in the payer's pocket. Camera, screen, compute, network connection, app — everything an acceptance terminal needs, a smartphone already has.

This is the pivotal step in the whole thing: the cost of the acceptance terminal did not vanish, it was transferred to someone who was buying that device for other reasons anyway. The payer bought a phone to chat, watch video, and navigate. Paying just borrows hardware that has already been paid for. So on the merchant's books, that cost looks like it evaporated.

This also explains why the gap from the previous chapter — phone penetration running ahead of bank penetration — matters so much. This design requires the payer to have a smartphone, a connection, and an account he can pay from, and requires the merchant to have nothing at all. The more phones and the fewer bank branches a market has, the bigger this design's advantage there.

Second: a central ledger that can never go offline

This one is the easiest to overlook, and it is the entire subject of the next several chapters.

A static code holds one merchant ID. That string by itself does nothing — it has to be carried somewhere, and that somewhere has to answer three questions: who is this ID; is this person still a valid merchant; does the payer have enough money.

Answering those three requires two things: a ledger holding every account balance, and a merchant directory recording which ID belongs to whom. The institution running that apparatus is from then on obliged to be real-time, online, and never down.

Compare cards: a card has a chip, the chip can make some of the judgement itself, the terminal can set a floor limit below which no authorization is needed, and if the link drops it can record now and submit later. That "local decision capability spread across tens of thousands of terminals" was built up by decades of time and decades of equipment investment. The QR design has none of it, and needs none of it — it pulls the judgement entirely back to the centre.

Cards scattered the intelligence across tens of thousands of terminals; the QR design pulls all of it back into one centre, so the terminal can be a piece of paper and the centre cannot stop for a second. The cost moved from procuring and maintaining tens of thousands of devices to one institution's ledger, directory, and duty of continuous operation.

One very concrete piece of cost flows back, incidentally: a merchant with a static code has no idea whether the money arrived. Which is why little shops in China ended up with a speaker box whose only job is to announce "Alipay, twenty yuan received." Once device cost was pushed to zero, a small part of it grew back — but it is now optional, and it costs a few tens of yuan.

That ledger, that directory, and that obligation never to stop all have to be built by someone and paid for by someone. Who builds it and who pays is the entire argument that starts in the next chapter.

Third: a new category of fraud, landing on the payer

Sticker-swap fraud: someone takes a sticker with his own receiving code on it and pastes it over the merchant's. The customer scans the sheet on the wall, and the money lands in the fraudster's account. The merchant, standing right there, sees nothing unusual, because at no point in the process does he touch a device or take part in anything.

Static codes are unusually fragile here, for exactly the reason in the last row of that earlier table:

• It never changes, so the fraudster has time to prepare and time to pick a moment when nobody is looking.
• It carries no amount and no order number, so two different codes look equally unfamiliar on the customer's phone — the payer never knew what name that merchant ID maps to, so "pay Such-and-Such Trading Co." raises no eyebrow.
• The merchant has no device, so no end of the chain will ever flag "that isn't my code."

Dynamic codes are much better. Generated fresh per payment, bound to an order, dead within minutes; pasting a fake one in gets you one payment at most, and the till system on the other end notices immediately that this order was never paid.

Consumer-presented QR moves the risk somewhere else. That screen of code in the payer's app is essentially a pay-on-sight credential: whoever scans it can debit the payer's account with it. It does not check who you are. So screenshotting it to someone, or having someone photograph it over your shoulder, is handing over money — which is why these codes always refresh every few dozen seconds and why apps generally forbid screenshots.

Of the three cost transfers, the first two moved money to a different place; the third manufactured a category of loss that did not exist before, and the person carrying it is the payer. One sheet of paper can be stuck up, and so can somebody else's sheet of paper — that is one property with two faces, which lines up exactly with the previous chapter's line that capability and barrier are two sides of the same thing.

7. One Code, Readable by More Than One Party: EMVCo's Specification¶

Everything so far is internal to one country and one scheme. Step one pace outside and you hit a question: that string of characters inside the code — who defined the format?

A code is a string. If every payment institution decides for itself how that string is laid out, then a code can only be understood by the app of the institution that generated it. The merchant's table ends up with a row of stickers on it, and the customer has to find his own. That is not hypothetical; a lot of markets looked exactly like that early on.

EMVCo published a QR specification, in two flavours, matching the two directions above:

• MPM, merchant-presented mode.
• CPM, consumer-presented mode.

What the specification does is plain enough: it dictates which segment of that string holds what, so a code can be read by apps from different schemes without any prior arrangement.

It does not solve how the money clears, or who charges whom how much, or the exchange rate between two countries. It solves "readable" and nothing more. That is the first step towards interlinking, and the easiest one. By the Southeast Asia chapter you will see that once things are readable, the hard part begins — Southeast Asia's fragmentation covers a set of interlinking connections, many of them live, carrying astonishingly little volume.

But one thing is worth carrying through the whole course: who owns EMVCo.

EMVCo is owned in equal shares by six card networks: Visa, Mastercard, American Express, Discover, JCB and UnionPay. It is not a neutral international standards body. It is the card networks' consortium.

Which produces the most interesting structure in this course: Brazil's Pix, Thailand's PromptPay, Malaysia's DuitNow, Singapore's PayNow, Hong Kong's HKQR, Indonesia's QRIS, Vietnam's VietQR — the national codes people produce as proof that "A2A is displacing cards" — all use EMVCo's merchant-presented format. The rails built to go around cards speak a language the card networks wrote.

Does that mean the networks are collecting on it? No — the EMV specifications are published free of charge, and they take nothing here.

Which is exactly the point. Look back at Denso Wave at the start of this chapter: no toll gate means fast spread, and spread fast enough and you become the default reference. What the networks hold at this layer is not a fee, it is a seat: where the format goes next, what fields the next version adds, whose specification cross-border linkage aligns to. Charging and having influence are two entirely different things.

This is only the first place they reached into. the financials do not show it puts it next to the rest.

8. A Code Is Not a Rail: The Sticker Only Solves Initiation¶

EMVCo's specification makes one code readable by different apps. And after it is read? Being readable only means the phone knows who to pay and how much. Not a cent has moved.

So here is a rule, set as early as possible, because the next twelve chapters all run on it:

A QR code is a form factor, not a rail.

Taken apart:

• The form factor determines how a user initiates a payment — scan a code, type a phone number, get redirected to a bank, read out a one-time six-digit code.
• The rail determines how money moves from one account to another — who clears, who settles, seconds or overnight.

The code itself does not move money. It is a piece of encoded collection information, and the payment that actually happens after the scan runs on the rail underneath it.

Why does this matter? Because three quite different things can sit under a code, and their economics are opposites:

The third row is the one people drop: a transaction initiated by code and running on a card underneath is still a card transaction. Interchange is still paid, the chargeback right still applies, and it still lands on the issuer's book. The form factor changed and the bill did not move at all.

So "this country scans codes" and "this country is off cards" are two different statements, with no necessary link between them. Every chapter from here covers one market, and what is actually being compared is the middle column — who built that rail and who funds it. What the code looks like turns out to be the least important layer.

The rule also runs in reverse: not scanning is not the same as being behind. Australia's entire instant rail has essentially no codes, Poland uses a one-time six-digit code, the Netherlands uses a bank redirect — and all of them have local rails that work very well. the rail map breaks this into four layers with a comparison table across eleven markets.

9. The Question This Chapter Leaves Open¶

Compress this chapter into one sentence: the QR code invented no new payment relationship, it redistributed cost. Merchant-side hardware cost fell to a printing charge, institutional cost went from a sales visit to a self-service submission, and the price was that terminal cost moved onto the payer's phone, decision capability moved into a centre that can never go offline, and the payer picked up an extra category of fraud.

Which makes the new question clear.

A sticker is cheap. What stands behind it is not: a real-time ledger, a national merchant directory, an ability to run without stopping, a team handling fraud and complaints. Who builds that, who pays to keep it running, and who decides what the merchant should be charged?

There is no single answer. Three countries gave three completely different ones: in one, two private companies raced to build it; in one, a clearing house jointly owned by the banks built it and the merchant fee was set to zero by law; in one, the central bank built it itself and forced the large institutions to join. Three ways of building produced three completely different markets, with merchant cost running from zero to 0.6%.

Start with the one that got there first: with no state mandate, how did two companies take a country's checkout — the Chinese duopoly.

10. Self-check questions¶

1. For merchant-presented and consumer-presented QR, which side has to be online in each case? How does that decide which kind of merchant each one suits?
2. A static code contains no amount. That single omission brings one advantage and one risk. What are they?
3. "The QR code cut merchant acceptance cost to zero" — where is that sentence right, and where is it wrong?
4. Denso Wave held QR patents and charged nothing for them. What would have happened if it had charged? Compare that against the cost structure of NFC acceptance.
5. A card acceptance network lets tens of thousands of terminals each make part of the judgement; the QR design cannot. Why? And who does that difference push the cost onto?
6. What does the "form factor" determine and what does the "rail" determine? Which three things can sit under a code, and in which case do the card networks still get paid?

11. Answers¶

Answer for yourself before reading on.

1. Merchant-presented QR requires the payer to be online: the code is inert, and the payment instruction leaves from the payer's app. Consumer-presented QR requires the merchant to be online: the screen of code is only a credential, and the debit request is raised by the merchant's acquiring chain. So merchant-presented QR suits long-tail merchants with no device and no connection at all — stallholders, street-side sellers, individuals; consumer-presented QR suits chains with a till system that need a few seconds per customer, because a scan gun is far faster than a customer bending over a phone typing an amount.

2. The advantage is that the merchant needs no device whatsoever: the payer enters the amount, the code is printed once and lasts years, and hardware cost equals the printing charge. The risk is that the code never changes and carries no order information, so someone has time to paste his own over it, and neither the payer nor the merchant can see anything wrong — the payer never knew that merchant's name anyway, and the merchant has no device that could flag it. Dynamic codes close both holes.

3. The right part is hardware cost: not cheaper, gone, with only a printing charge left. The wrong part is institutional cost: the merchant still has to open a receiving account at a licensed institution, still has to pass identity checks, get an ID, and accept a settlement arrangement. That did not go to zero. It only went from "a salesperson makes a trip" to "the merchant submits in an app and a back office reviews in bulk." Labour cost fell; the review itself is still there.

4. There would have been a toll gate, and spread would then be set by the toll collector's commercial judgement rather than by demand. NFC acceptance looks exactly like that: the merchant must buy a certified device, and along the chain the device maker, the certification body, and the licensor each take a slice, and a spec upgrade means touching every device in the field. On the QR side there is nobody who can charge and nobody who can block, so a sheet of paper can enter any market at all. No toll gate is the first reason it spread, and that has nothing to do with technical merit.

5. Because a card has a chip, and the terminal holds a security module and rules, so it can make part of the authorization decision locally, set a floor limit, and record offline then submit later. That distributed local intelligence was built by decades of equipment investment. The sheet of paper holds nothing but a merchant ID, so every judgement can only happen at the centre. The cost therefore lands on the institution operating the scheme: a real-time ledger, a merchant directory, and a duty never to stop for a second. That is why the terminal can be a piece of paper and why the centre must always be online.

6. The form factor determines how a user initiates a payment (scan, phone number, redirect, six digits); the rail determines how money moves from one account to another (who clears, who settles, how fast it lands). Three things can sit under a code: a bank instant clearing rail (India, Brazil, Singapore, Thailand), the wallet's own ledger (China's closed loop), and a card. In the third case the card networks still get paid — a transaction initiated by code and running on a card is still a card transaction, interchange and the chargeback right included. So "scanning codes" and "off cards" are two different statements.

Previous: Chapter 1 · The Three Assumptions of a Card: A Terminal, a Credential, and an Interchange Fee Next: Chapter 3 · China: How Two Companies Took a Country's Checkout