Chapter 19 — QR Codes, Proxies & Pay-by-Scan

Jakarta, Indonesia. It's a humid Tuesday evening in 2019, and Rina — MakanKaki's newly appointed expansion lead — is weaving through the narrow lanes of a Jakarta hawker center, scouting stalls for the platform's Indonesia launch. She counts the QR codes the way a birdwatcher counts species. The nasi goreng guy has three acrylic standees: GoPay, OVO, Dana. The juice cart next door has four — those three plus LinkAja. Every code belongs to a different app, a different closed loop, a different universe of money that doesn't talk to the others.

She watches a bewildered Australian tourist try to pay for satay. He opens GoPay — wrong code. Tries OVO — the app throws an error because the merchant hasn't linked that account. The tourist gives up and pays cash, muttering something about "cashless society."

Then Rina spots something different. A bakso stall at the end of the row has a single QR standee. One code. One small logo: QRIS. She watches a GrabBike driver scan it with GoPay. A college student scans the same code with ShopeePay. An older woman scans it with her BCA bank app. Three different apps, three different providers, one QR code — and all three payments sail through.

One QR, any app.

Rina pulls out her notebook and writes a single line: "The QR code isn't the payment. It's the front door."

That distinction — between the thing you see and the infrastructure you don't — is what this chapter is about. In Chapter 18, we walked through the rails: real-time payment networks, bank transfers, the push-and-pull mechanics that actually move money between accounts. Now we're going to explore the interface layer that sits on top of those rails. QR codes, proxy identifiers, and pay-by-scan systems didn't invent new ways to move money. They invented new ways to start a payment — and in doing so, they turned every phone camera into a point-of-sale terminal and every printed square into a merchant checkout.

Let's pull back the curtain.

QR Is Not a Rail: The Interface Layer

Here's the single most important thing to understand about QR code payments: a QR code is not a payment method. It's an encoding format. A QR code is a way of stuffing information — a merchant ID, maybe a transaction amount, a currency code — into a square grid of black-and-white pixels that a phone camera can read in a fraction of a second. That's it.

The actual payment — the part where money leaves your account and arrives in someone else's — travels on a rail underneath. In India, that rail is UPI. In Brazil, it's Pix. In Indonesia, it's the BI-FAST network (or a wallet's internal ledger). In Mexico, it's SPEI. The QR code is just the input method, the way you tell your phone who to pay and how much. It's the difference between a doorbell and the person standing behind the door.

This matters because people constantly confuse the two. You'll hear someone say "QR payments are the future" as if the QR itself is doing something magical. It isn't. What's magical is the combination: a zero-cost interface layer on top of an instant payment rail. The QR provides convenience. The rail provides movement. Together, they're lethal to cash — but you have to understand which piece is doing what.

Static vs. Dynamic: Two Flavors of the Same Idea

Walk into a street market anywhere in Southeast Asia, and you'll see QR codes that have clearly been there for months — laminated, sun-bleached, maybe taped to a cash register or propped up in an acrylic standee. That's a static QR code. It's printed once and never changes. All it contains is the merchant's identifier — essentially a digital address that says "this is where the money should go." When you scan a static QR, you type in the amount. The merchant trusts you to enter the right number.

Now walk into a convenience store or a larger restaurant, and you might see a different experience. The cashier taps a total on their screen, and a fresh QR code appears on a customer-facing display. That's a dynamic QR code — generated per transaction, encoded with the exact amount, a unique transaction reference, and sometimes an expiration timestamp. You scan it, confirm the amount your app shows you, and tap pay. No manual entry.

The trade-offs are intuitive. Static QR codes cost almost nothing — you print them once and you're done. They're perfect for the bakso stall, the street-side tailor, the parking attendant. But they push responsibility onto the customer to enter the correct amount, and reconciliation is harder for the merchant because there's no automatic link between the QR scan and a specific order. Dynamic QR codes require a device to generate them — a phone, a tablet, a POS terminal — but they eliminate amount errors and make reconciliation trivial because every code maps to exactly one transaction.

Who Shows the Code: MPM vs. CPM

There's a second axis that matters just as much. In merchant-presented mode (MPM), the merchant displays the QR code and the consumer scans it. This is the hawker center model — the printed standee, the screen at the checkout counter. Your phone is the scanner. In consumer-presented mode (CPM), the flow reverses: you display a QR code on your phone screen, and the merchant scans it with a reader or camera. Think of the Starbucks app, or tapping through a subway turnstile in China where a scanner reads the barcode on your screen.

The distinction isn't just cosmetic. It changes the hardware requirements, the risk profile, and who controls the transaction. MPM is cheap for the merchant — a printed piece of paper will do — but the consumer's phone needs a working camera. CPM requires the merchant to have a scanner, which adds cost, but it's faster in high-throughput environments like transit gates and drive-throughs. CPM also shifts some fraud exposure: the code on your screen is typically dynamic and short-lived, making it harder to copy. A static MPM code, by contrast, could theoretically be swapped out by a bad actor who pastes their own QR over the merchant's.

Why QR Beat Cards for Micro-Merchants

If you're Rina, standing in that Jakarta hawker center, the appeal is obvious. A card terminal costs money — the device, the connectivity, the merchant agreement, the wait for settlement. A printed QR code costs the price of a sheet of paper. There's no hardware to buy, no power source needed, no PCI compliance to worry about. The merchant gets paid in seconds (because the underlying rail is real-time), and because QR-initiated payments are overwhelmingly push payments — the customer sends money rather than the merchant pulling it — there's no chargeback infrastructure to build. The customer authorized the push. It's done.

This connects directly to the push-versus-pull framework from Chapter 18. Most QR payment systems ride on push-based rails. The consumer scans, confirms, and pushes funds. The merchant never touches the consumer's account credentials. That one architectural choice — push, not pull — eliminates entire categories of fraud and dispute management that the card networks spent decades building.

And the final ingredient: cameras are already universal. Every smartphone made in the last decade has one. QR codes don't need NFC chips, don't need Bluetooth, don't need special hardware on either side. A camera and a printed square. That's the whole stack for the simplest deployment.

What's Actually Inside the QR

You might be curious what a QR payment code actually encodes. The EMVCo QR Code Specification — the closest thing to a global standard — defines a structured payload. When your phone's camera decodes the pixel grid, it finds a string of data organized into tagged fields. The key ones include a Payload Format Indicator (which version of the spec this is), a Point of Initiation Method (static or dynamic), Merchant Account Information (the actual routing details — which network, which account), Transaction Currency, Transaction Amount (present in dynamic codes, absent in static ones), Country Code, Merchant Name, Merchant City, and a CRC checksum at the end to catch scanning errors. Each field has a two-digit ID tag and a two-digit length prefix, making the whole thing machine-parseable in milliseconds.

And the layered architecture is worth pausing on, because it explains why QR codes are so adaptable across completely different payment systems.

The QR code is just the top layer — the input method. Beneath it, a proxy resolution step translates the merchant identifier in the QR into actual account routing details. Below that, the instant payment rail moves the money. And at the bottom, settlement finalizes the transfer. Swap out any layer and the others still work. You could replace the QR code with an NFC tap or a typed phone number and everything below it stays the same. That modularity is the whole point.

But here's the thing — knowing who a merchant is from a QR code is only half the problem. The QR tells your app a merchant identifier, but something still has to translate that identifier into an actual bank account or wallet address. And for person-to-person payments, you don't want to scan a QR code every time you split a dinner bill — you want to type a phone number or an email address and have the system figure out the rest. That translation layer is called a proxy identifier, and it's the invisible directory that makes modern payment systems feel effortless. Let's look at how it works.

Proxy Identifiers: Hiding Complexity from Users

Think about the contacts app on your phone. You tap "Mom" and your phone figures out the rest — carrier routing, country code, whether it's a mobile or landline. You never think about any of that. You just tap the name.

A proxy identifier does the same thing for payments. It's an alias — a phone number, an email address, a tax ID, even a made-up string — that maps to the full set of bank account coordinates hiding underneath. The payer never needs to know the payee's bank name, branch code, or account number. They just need the alias, and a central directory handles the translation.

This is tokenization in the broadest sense. The proxy is a token. It means nothing on its own. But feed it into the right directory, and it resolves into everything the payment system needs to route money to the correct account at the correct institution. The directory is the magic — the proxy is just the front door.

The Global Proxy Landscape

Different countries have built their own versions of this directory, and the design choices they've made reveal a lot about what each system prioritizes.

In India, UPI uses Virtual Payment Addresses — VPAs that look like email addresses. Rina's VPA might be rina@okaxis, which tells the UPI system to resolve her account through the Axis Bank PSP. The format is human-readable and easy to share. You can even create multiple VPAs tied to different bank accounts and switch between them.

Brazil took a different approach with Pix keys. When the Central Bank designed Pix, they let users register up to five key types as proxies: a mobile phone number, an email address, a CPF or CNPJ (the Brazilian tax identification numbers for individuals and businesses), or an EVP — a random 32-character key for people who don't want to share personal information. The Central Bank describes these keys as "nicknames" that represent a user's transactional account information. Simple and elegant.

Singapore's PayNow system maps proxies to bank accounts using a mobile number, an NRIC or FIN (national identity numbers), or a UEN for businesses. It's tightly integrated with the national identity infrastructure, which makes onboarding fast but limits the system to identifiers the government already controls.

In Mexico, DiMo (short for Dinero Móvil) enables transfers using only the receiver's phone number. Banco de México built it as a phone-number aliasing layer on top of the existing SPEI rail. And in Colombia, Bre-B lets users register aliases using their national ID, cell phone number, email, an alphanumeric code, or a business code — one of the most flexible proxy menus

anywhere.

Here's how the major proxy directories compare:

Why the Directory Matters More Than the QR Artwork

It's tempting to focus on the QR code itself — the black-and-white square, the encoding format, the payload structure. But the directory behind the proxy is where the real action happens. Three things make or break a proxy system.

1. Portability. Can you take your proxy with you when you switch banks? In Brazil, Pix keys are fully portable — you can migrate a key from one institution to another. In systems without portability, your alias is locked to your current provider, which creates switching costs and undermines competition. The directory's rules on portability shape the entire competitive landscape.
2. Duplicate prevention. A phone number can only point to one account at a time. If someone registers your number at a different bank, what happens to your existing registration? Well-designed systems require explicit consent and deregistration before a proxy can be reassigned. Poorly designed ones create silent overwrites and misdirected payments.
3. Lookup security. A directory full of phone-to-account mappings is an incredibly attractive target. Attackers can enumerate the directory — trying phone numbers sequentially to figure out who banks where. Rate limiting, partial name masking (showing "Ra Si" instead of "Rina Sari" during verification), and anomaly detection are all essential defenses.

When Proxies Go Wrong

The most common attack vector is the SIM swap. If your proxy is your phone number and an attacker convinces your carrier to transfer your SIM to a new device, they can intercept OTPs, re-register your proxy, and redirect your incoming payments. India, Brazil, and Singapore have all seen variants of this attack, and each has layered on additional verification — device binding, cooling-off periods for proxy changes, and carrier-level SIM swap alerts.

Then there's social engineering with look-alike aliases. In systems that allow freeform usernames (like UPI's VPAs), an attacker might register rina.sari@okaxis when the real Rina uses rinasari@okaxis. The difference is a single period, easy to miss when someone shares their alias over chat.

And sometimes the directory simply gets it wrong. A misdirected payment — money sent to the right proxy but the wrong underlying account because of a stale mapping — is difficult to reverse in real-time payment systems. The money moves in seconds, and clawing it back requires cooperation from the receiving bank, the recipient, and often a regulator.

These aren't theoretical risks. They're the reason every proxy system invests heavily in that brief moment of recipient verification — showing you the payee's name before you confirm the payment. That single UX step, as we're about to see, is one of the most important fraud-prevention tools in the entire flow.

The Scan-to-Settle Flow: End-to-End

Let's go back to the Jakarta hawker center. It's lunchtime, and you're standing in front of Pak Ahmad's bakso stall. The steam is rising, the broth smells incredible, and taped to the front of his cart is a laminated QRIS code — the same one he's used for months. Time to pay.

Here's exactly what happens in the two or three seconds between you pointing your phone at that QR code and Pak Ahmad hearing the chime that says your money arrived.

Step by Step Through the Payment

You open MakanKaki's app — or GoPay, OVO, ShopeePay, or any QRIS-compatible wallet — and tap the scan button. Your phone's camera reads the QR code and decodes the payload. Inside that payload is Pak Ahmad's merchant identifier, his acquiring institution's code, and a flag indicating this is a static QR — meaning there's no pre-filled amount. The app now knows who you're paying, but not yet how much.

Behind the scenes, your app resolves the merchant identifier. It checks the QRIS directory to translate that identifier into a display name. Your screen shows: "Warung Bakso — Pak Ahmad." This is the recipient verification step, and it matters enormously. If the name looks wrong — if it says "Electronics Store" instead of a bakso stall — you know something is off before any money moves.

You type in Rp 35,000 for your bowl of bakso. You confirm. Your app prompts for authentication — a six-digit PIN, a fingerprint, or a face scan depending on your device and your wallet's security settings. You authenticate.

Now the machinery kicks in. Your wallet provider (the payer PSP — let's say it's GoPay) packages the payment instruction and sends it to BI-FAST, Bank Indonesia's real-time payment switch. BI-FAST routes the instruction to Pak Ahmad's bank (the payee PSP). The payee PSP credits Pak Ahmad's account — or more precisely, makes the funds available, even if final interbank settlement happens in a later batch. The payee PSP confirms back through the switch.

The confirmation cascades: payee PSP to BI-FAST, BI-FAST to GoPay, GoPay to your app. Your screen flashes green. "Payment Successful — Rp 35,000 to Warung Bakso — Pak Ahmad."

And on Pak Ahmad's end? His phone buzzes with a push notification from his bank app. If he's got a soundbox — those small Bluetooth speakers that many Indonesian merchants use — it announces the payment with an audible chime. He nods, slides your bakso across the counter, and you're done.

One to three seconds, start to finish.

The Details That Matter

A few things in this flow deserve a closer look.

1. Recipient verification is a fraud gate. That moment where the app shows Pak Ahmad's name before you confirm? It's not just a courtesy — it's one of the strongest anti-fraud signals in the system. If someone swapped Pak Ahmad's QR with their own, the name mismatch is your first and best warning. This is why well-designed systems always display the resolved name and give the customer a chance to cancel.
2. Authentication happens at the payer's app, not the switch. BI-FAST doesn't know or care whether you used a PIN or your fingerprint. That's between you and your wallet provider. This is a deliberate design choice — it keeps biometric data local to the device and the PSP, rather than centralizing it in national infrastructure.
3. The merchant should trust the PSP notification, not the customer's screen. This is a real and growing fraud vector: customers show a fake payment confirmation screenshot and walk away with their food. Pak Ahmad's soundbox solves this by providing an independent confirmation channel. The chime comes from his bank, not from anything the customer controls. Merchants who rely on glancing at the customer's phone screen are vulnerable.
4. "Credited" doesn't always mean "settled." When Pak Ahmad's bank makes the funds available, that's a credit — the merchant can use the money. But the actual interbank settlement between GoPay's bank and Pak Ahmad's bank might happen later in a deferred net settlement batch, just like we covered in Chapter 18. The customer and the merchant both experience real-time, but the banks square up on their own schedule.

Same Building Blocks, Different Assemblies

Step back and look at what we've just walked through: a QR encoding standard, a proxy directory, a real-time payment switch, PSP-level authentication, and a notification layer. These are the building blocks. Every country that has built a scan-to-pay system uses some combination of them.

But the way each country assembles these blocks — who operates the directory, whether QR codes are standardized or proprietary, how settlement works, what proxy types are supported — varies dramatically. India's UPI, Brazil's Pix, Singapore's SGQR with PayNow, and Indonesia's QRIS each made different architectural choices that reflect different priorities: financial inclusion, competition, interoperability, or central bank control.

Those differences are exactly what we need to unpack next. Let's take a tour through the major national implementations and see how each one solved — or is still solving — these design puzzles.

Country Deep Dives: Same Building Blocks, Different Recipes

Every country we're about to visit had access to the same toolkit. QR standards. Proxy directories. Instant payment rails. Fee policies. Interoperability mandates. Think of them like ingredients in a kitchen — flour, eggs, sugar, butter, salt. Every baker has them. But a French croissant tastes nothing like an American biscuit, and neither one resembles a Brazilian pão de queijo.

The same thing happened with payments. India, Indonesia, Brazil, Singapore, Mexico, and Colombia each reached into roughly the same ingredient bin and came out with remarkably different systems. Some prioritized inclusion over revenue. Others chose interoperability over speed-to-market. A few tried to do everything at once — with mixed results.

For MakanKaki, our food delivery platform expanding across Southeast Asia and Latin America, these aren't academic differences. They determine which integrations you build, what fees you pay (or don't), and whether a street-food vendor in Yogyakarta can accept the same payment as a restaurant in São Paulo.

Let's walk through each country and see what they prioritized — and what happened because of it.

India: UPI QR as Digital Public Infrastructure

If you want to understand what happens when a government treats payments like a public utility — the way it treats roads or the postal system — look at India.

The Unified Payments Interface (UPI) isn't a single app. It's a common rail operated by the National Payments Corporation of India (NPCI) that dozens of apps ride on top of. PhonePe, Google Pay, Paytm, CRED, WhatsApp Pay — they all speak the same protocol. A customer using Google Pay can scan a QR code generated by a PhonePe merchant. No special arrangement needed. No bilateral deal. The rail handles it.

The numbers are staggering. In January 2026 alone, UPI processed 16.99 billion transactions worth ₹23.48 trillion. That's not a typo — nearly 17 billion transactions in a single month.

How did India get here? Three design choices made all the difference.

First, zero MDR. The Government of India issued a circular eliminating the merchant discount rate on UPI and RuPay transactions entirely. No percentage fee. No per-transaction charge. Nothing. If you're a tea-stall owner in Chennai, accepting a digital payment costs you exactly the same as accepting cash: zero. This single policy decision removed the biggest obstacle to merchant adoption overnight.

Second, the "tea-stall test." UPI QR acceptance requires nothing more than a printed piece of paper and the customer's phone. No terminal to lease. No monthly subscription. No chargeback process to navigate. A merchant literally prints a QR code, tapes it next to the register, and starts accepting payments from any bank account in India. The average UPI transaction sits at roughly ₹1,293 — about $15 — confirming that people use it for the smallest everyday purchases: chai, auto-rickshaw rides, vegetable shopping.

Third, soundboxes solved the trust gap. When you hand someone cash, you both see it happen. When a customer shows you a phone screen confirming payment, how do you know it's real? Fake payment screenshots became a genuine problem. The answer was soundbox devices — small Bluetooth speakers from PhonePe (SmartSpeaker) and Paytm (Soundbox) that audibly announce each payment in the merchant's language. "Payment received: two hundred rupees." They cost roughly ₹1,000–2,000 ($12–24), often subsidized by the payment apps, which monetize through subscription fees or advertising. It's a beautifully low-tech solution to a high-tech problem.

Behind all of this sits the broader infrastructure stack: Aadhaar-linked bank accounts that gave hundreds of millions of people a financial identity, rising smartphone penetration, and government subsidy disbursements flowing through UPI that gave people a reason to set it up in the first place. India didn't just build a payment system. It built digital public infrastructure — and QR codes were the on-ramp.

Indonesia: QRIS as National Interoperability Standard

Remember Rina from our opening — standing at a Jakarta food stall, staring at four different QR codes and guessing which wallet the vendor actually used? That wasn't a hypothetical. That was Indonesia before 2019.

The problem was wallet fragmentation. GoPay, OVO, Dana, and LinkAja had each built their own proprietary QR ecosystems. Merchants either picked one and alienated customers using the others, or plastered their counter with a patchwork of codes and hoped for the best. It was messy, confusing, and exactly the kind of friction that keeps people using cash.

Bank Indonesia fixed it by mandate. In August 2019, it launched QRIS (Quick Response Code Indonesian Standard), built on the EMVCo QR specification. Compliance became mandatory on January 1, 2020. The core promise was simple: any app scans one QR. A GoPay user, an OVO user, a bank mobile app user — they all scan the same code, and the system routes the payment correctly.

Adoption followed. By October 2025, QRIS had reached 58.3 million users and 41.19 million merchants, according to Bank Indonesia's Annual Meeting data. For a country of 270+ million people spread across 17,000 islands, that penetration is significant — and still climbing.

Indonesia used fee policy as an adoption lever, much like India, but with more nuance. Micro merchants — those processing transactions up to a certain threshold — pay 0% MDR. Above that, fees are tiered. And crucially, merchants are prohibited from passing the MDR on to consumers. The customer never sees a surcharge. This sounds like a small regulatory detail, but it matters enormously for perception. The moment a customer gets charged extra for scanning a QR code, they pull out cash instead.

Where Indonesia gets especially interesting for MakanKaki is cross-border interoperability. QRIS has live linkages with Singapore's NETS QR and Malaysia's DuitNow QR. A Singaporean tourist in Bali can open their local banking app, scan a QRIS code, and pay — with the currency conversion handled behind the scenes. For a food delivery platform operating across these markets, one QRIS integration means acceptance from every wallet and bank in Indonesia. That's the interoperability dividend.

Brazil: Pix as the New Default

Brazil didn't tiptoe into instant payments. It cannonballed.

Pix launched in November 2020, and the Central Bank of Brazil made participation mandatory for all large financial institutions from day one. Not optional. Not "encouraged." Mandatory. If you were a bank above a certain size, you were on Pix whether you wanted to be or not.

The proxy layer — called Pix keys — gives users five ways to link their accounts: phone number, email, CPF (the Brazilian individual tax ID), CNPJ (the business tax ID), or a randomly generated key. You pick whichever you're comfortable sharing. Want to receive money from strangers without giving out your phone number? Use a random key. Want your business to be easily findable? Register your CNPJ. This flexibility meant people didn't have to compromise on privacy to get convenience.

The scale Pix achieved is extraordinary. Roughly 170 million users — in a country of 215 million. Around 64 billion transactions in 2024, moving roughly BRL 26 trillion (about $4.6 trillion) in value, according to the Central Bank of Brazil's Pix statistics. To put that in perspective, Pix went from zero to ubiquity in under four years.

QR codes are one of Pix's payment initiation methods, sitting alongside key-based transfers and, increasingly, NFC. At a restaurant, you might scan a QR code. Sending money to a friend, you'd type their phone number. The underlying rail is the same — instant, 24/7, account-to-account settlement.

For consumers, Pix is free. For businesses, institutions may charge fees, but the competitive pressure keeps them low. The real monetization frontier has shifted to value-added services: credit offerings triggered by transaction data, insurance products, cash management tools built on top of the Pix rail.

Brazil is now expanding the system's capabilities. Pix Automático introduces recurring payments — think subscription billing over instant rails. Your gym membership, your streaming service, your MakanKaki meal plan — all debited automatically via Pix. This pushes instant payments into territory traditionally owned by credit cards and direct debit.

Perhaps the most telling indicator of Pix's success isn't a statistic at all. "Manda um Pix" — "send a Pix" — has entered Brazilian Portuguese as a verb, the same way "Google it" entered English. When your payment system becomes a verb, you've won.

What did Brazil get right? Mandatory participation eliminated the cold-start problem. Zero consumer cost removed adoption friction. Rich proxy options gave people control. And an aggressive timeline — regulation to launch in under two years — created urgency that prevented institutional foot-dragging.

Singapore: The Interoperability Lab

Singapore's payment story isn't about massive domestic scale. With a population under six million and card acceptance already deeply established, the city-state was never going to produce UPI-sized transaction volumes. Instead, Singapore became something arguably more interesting: a laboratory for cross-border interoperability.

Domestically, SGQR tackled the QR clutter problem by consolidating multiple payment scheme codes into a single unified label. One QR sticker on the counter, multiple schemes encoded within it. Clean, practical, very Singaporean.

PayNow serves as the proxy directory, letting users link their mobile number, NRIC/FIN (national ID), or UEN (business registration number) to their bank account. Person-to-person transfers are instant and free. For small merchants and government services — hawker stalls, community centers, parking — QR-based PayNow fills a niche where deploying a card terminal doesn't make economic sense.

But Singapore's real contribution is what happens at the borders. The PayNow-PromptPay linkage with Thailand went live in 2021, letting users in either country send money to the other using just a mobile number. PayNow-DuitNow connects Singapore and Malaysia. These aren't theoretical pilots. They're live, production systems handling real money.

The ambition goes further. The BIS Project Nexus — targeting a 2026 multi-country instant payment platform — counts Singapore as a key participant. The vision: a standardized protocol that lets any participating country's instant payment system talk to any other's, without building individual bilateral linkages.

For MakanKaki, Singapore is home base. The cross-border linkages mean that when a Thai tourist opens the MakanKaki app in Singapore, they could potentially pay using PromptPay through their Thai banking app. Malaysian customers could do the same via DuitNow. The payment follows the customer, not the other way around.

Mexico: When Great Infrastructure Meets Modest Adoption

Mexico has one of Latin America's most mature real-time transfer systems. SPEI — operated by Banco de México — has been moving money between bank accounts in seconds for years. It's a genuinely impressive piece of infrastructure: hybrid clearing, near-instant settlement, reliable at scale.

So when Mexico built CoDi — a QR and NFC payment overlay on top of SPEI — it seemed like a sure thing. The ingredients were all there. Fast rails. Central bank backing. A mandate requiring qualifying banks to accept CoDi transactions. Even the branding emphasized the value proposition: "sin comisiones" — no commissions.

Then came DiMo, a phone-number aliasing service for SPEI transfers. By the end of 2024, DiMo had 12.2 million registered users — though far fewer were actively transacting. Respectable numbers, but not transformative.

Here's the blunt truth: CoDi's daily average transaction value hit just MXN 10.6 million in December 2024. That's a rounding error next to what SPEI moves before breakfast. The infrastructure is excellent. The adoption is not.

What went differently compared to Pix and UPI? Several things compounded. Mandatory participation wasn't universal — smaller institutions could opt out, creating coverage gaps. Merchant incentives were insufficient to drive active promotion. Well-established card networks (Visa and Mastercard have deep roots in Mexico's formal economy) provided tough competition for consumer attention. And consumer marketing never reached the saturation levels that Brazil achieved with Pix.

Mexico's lesson is important for anyone building payment systems: infrastructure is necessary but not sufficient. You can build the fastest, most elegant rails in the world, but if the policy framework doesn't create strong enough incentives — and if the marketing doesn't reach the merchant behind the counter — people will keep using what they already know.

Colombia: Building in Real Time

Colombia is the newest entrant on this list, and it's building with the benefit of hindsight.

Bre-B — launched by Banco de la República — is explicitly positioned as an interoperable instant payment system spanning multiple financial institutions. The name is a play on the Colombian abbreviation for the central bank, and the system is designed from the ground up with the lessons of its neighbors baked in.

The alias framework is comprehensive: national ID (cédula), cell phone, email, alphanumeric code, and business code. QR payments were built in as a first-class capability, with rollout beginning in September 2025. This isn't a QR afterthought bolted onto an existing transfer system — it's integrated from the start.

One detail stands out. From launch, Bre-B's public communications have included strong anti-scam messaging: "Bre-B is not an app, does not have social media accounts." Colombia watched the fraud patterns that emerged in other markets — fake apps, phishing via social media accounts impersonating official channels — and decided to get ahead of them.

The market is still forming. Fee policy decisions haven't fully crystallized, and those decisions will strongly shape merchant uptake. Colombia's policymakers are clearly watching what worked in Brazil — mandatory participation, zero consumer cost — and what struggled in Mexico — optional adoption, insufficient incentives. The question is which recipe they'll follow.

For MakanKaki, Colombia represents future opportunity. The infrastructure is being laid right now, and platforms that integrate early will have a head start when the system reaches critical mass.

Every country on this list made a bet about fees. India eliminated them. Brazil made them invisible to consumers. Indonesia tiered them by merchant size. Mexico promised "no commissions" but couldn't drive the adoption to match. The pattern is clear: the payment itself is increasingly free or nearly free. So where does the money come from? How do payment providers, banks, and platforms like MakanKaki actually build a business when the core transaction costs nothing? That's exactly the question we need to answer next.

Business and Fee Models: Who Pays When the Rail Is "Free"?

The previous section laid bare an uncomfortable truth for anyone trying to build a payments business: governments across Asia and Latin America are systematically driving transaction fees toward zero. If you're MakanKaki, processing thousands of hawker stall orders a day across Singapore, Indonesia, and Brazil, the per-transaction margin on the payment itself is vanishing. So how does anyone make money?

The answer depends on which flavor of "free" your market chose. There are really three archetypes at work, and understanding them explains why some QR payment ecosystems are thriving commercially while others are struggling to attract private investment.

The Three Pricing Archetypes

Here's the question that haunts every payment provider in a zero-MDR world: if the transaction itself generates no revenue, what exactly are you selling? The answer turns out to be time, certainty, and intelligence — packaged as services that make the free payment rail actually useful for running a business:

1. Regulatory zero or near-zero MDR. India is the purest example. The government mandated that UPI transactions carry no merchant discount rate at all — not low, not subsidized, but zero. Indonesia takes a softer version of the same approach: micro-merchants pay nothing, while larger businesses pay a tiered MDR that scales with revenue. The logic is straightforward. Regulators decided that digital payment adoption is a public good, and they're willing to sacrifice fee revenue to get there.
2. Free for individuals, negotiable for businesses. Brazil's Pix sits here. Person-to-person transfers cost nothing. But when a business receives a Pix payment, their bank or PSP can charge a fee — and many do, though competition keeps those fees well below card interchange. The pricing is opaque to consumers, which is exactly the point. You never think about what the merchant pays when you scan a Pix QR code at a café.
3. Central-bank overlay framed as free. Mexico's CoDi promised "no commissions" as a headline feature, positioning itself as a costless alternative to both cash and cards. In practice, banks have little commercial incentive to promote a product that generates no direct revenue, which is one reason CoDi's adoption has lagged far behind Pix and UPI.

Where the Money Actually Comes From

If the transaction itself is free or nearly free, payment providers have to get creative. And they have. Across every major QR market, the real revenue comes from services layered on top of the payment rail.

1. Operational tooling is the first layer. Merchants need reconciliation dashboards, automated receipt generation, and transaction analytics. These aren't glamorous products, but they're sticky — once a hawker stall owner is checking her daily sales summary on a PSP's app every evening, she's unlikely to switch providers over a fraction of a percent in fees.
2. Soundbox confirmation devices have become a surprisingly lucrative business in India. Companies like Paytm charge merchants a monthly subscription for a small speaker that announces each incoming UPI payment with an audible confirmation. It sounds trivial, but for a busy street vendor who can't check a phone screen with every transaction, it's essential. Multiply a modest monthly fee across millions of merchants and you have a real revenue stream.
3. Merchant working-capital loans represent the biggest commercial opportunity. When a PSP processes every transaction flowing through a hawker stall, it knows that stall's revenue better than any bank does. That transaction data becomes the underwriting engine for small loans — a few hundred dollars to buy ingredients before a holiday weekend, repaid automatically from future payment inflows. The margins on lending dwarf anything a transaction fee could generate.
4. Finally, there's cross-selling: payroll services, inventory financing, accounting integrations, insurance products. Each one builds on the data and relationship established through payment acceptance.

The Platform Shift

This is what economists call the digital public infrastructure model. The government builds an open, interoperable payment rail — think of it like a highway. The highway itself is free to drive on. But the gas stations, restaurants, and rest stops along the highway are private businesses, and they do just fine.

For MakanKaki, this reframes the entire business model. If hawker stall acceptance is essentially free, there's no margin in being a payment intermediary. But there's enormous margin in being a merchant services platform — the company that helps hawker owners manage inventory, access working capital for a second stall, run payroll for their two employees, and track which dishes sell best on rainy days versus sunny ones. The payment becomes the entry point, not the product.

The pattern across all six markets points in the same direction: the payment rail commoditizes, and value capture migrates upward into the services built on top. But before MakanKaki — or any platform — can layer on those services, merchants need to actually operate with QR payments day to day. And that's a bigger shift than most people realize.

Merchant Operations: What Changes When You Move from Cards to QR

Switching from card acceptance to QR-based account-to-account payments isn't just swapping one logo on the checkout screen for another. The entire operational reality changes — how you confirm a sale, when you get your money, how you reconcile at the end of the day, and what your staff needs to know to avoid getting scammed. For a hawker stall owner in MakanKaki's network, these details are the difference between trusting the system and going back to cash.

Confirmation and Disputes Work Differently

With a card transaction, the flow is familiar. The terminal sends an authorization request, the issuing bank approves or declines, and you get an auth code. If something goes wrong later, there's a chargeback process — a structured, rules-based mechanism for disputing transactions that has been refined over decades by Visa and Mastercard.

QR-based A2A payments have none of that infrastructure. When a customer scans a QR code and their bank debits the funds, confirmation comes as a real-time notification — typically a push notification to the merchant's app, a webhook to their POS system, or an audible alert from a soundbox device. There is no authorization code in the traditional sense. And there is no chargeback process. If a customer wants their money back, the merchant initiates a refund or return through their PSP. The dispute resolution mechanism, to the extent one exists, is handled by the PSP or the central payment system's rules — not by a card network with decades of case law.

This matters for MakanKaki's hawker partners. A card chargeback can arrive 90 days after the sale. A QR refund request is typically immediate or near-immediate. The good news: merchants aren't exposed to the same delayed chargeback risk. The challenging news: they need a reliable, real-time confirmation signal, because there's no after-the-fact authorization record to fall back on.

Cash-Flow Timing Changes Everything

Here's where QR payments deliver a genuine operational advantage. Card settlements in most markets arrive T+1 or T+2 — meaning the money from today's sales hits your bank account tomorrow or the day after. For a hawker stall operating on thin margins, that delay matters. You sold $300 worth of chicken rice today, but you can't use that money to buy ingredients for tomorrow's prep until the settlement clears.

With UPI, Pix, and most real-time A2A systems, settlement is instant or near-instant. The money lands in the merchant's account within seconds. A hawker stall owner on MakanKaki's platform can literally restock ingredients during the lunch rush using revenue from that morning's breakfast service. For small merchants managing cash flow day by day — sometimes hour by hour — this isn't a minor improvement. It's transformational.

Static Versus Dynamic: The Operational Trade-Off

Not all QR codes work the same way, and the choice between static and dynamic QR has real operational consequences.

A static QR code is a printed image — laminated, taped to the counter, never changes. The customer scans it, enters the payment amount manually on their phone, and confirms. It's the cheapest possible setup. No hardware, no integration, no maintenance. But it creates two problems. First, the customer can mistype the amount — paying $5.00 instead of $50.00, or vice versa. Second, reconciliation is harder. When every transaction comes in as a generic credit to the same QR identifier, matching individual payments to specific orders requires manual effort.

A dynamic QR code is generated fresh for each transaction, encoding the exact amount and often an order reference number. It requires some form of POS integration — either a tablet, a terminal, or an API connection to MakanKaki's order management system. But it eliminates amount-entry errors and enables straight-through reconciliation, where each payment automatically matches to the order that generated it.

For MakanKaki's network, the split is natural. A hawker stall with a counter and a handwritten menu uses a static QR — it's simple, and the volume per stall is manageable enough for manual matching. MakanKaki's own online checkout and delivery orders use dynamic QR codes, because the platform needs automated order-to-payment matching across thousands of transactions per hour.

Two Failure Modes Every Staff Member Must Know

Training staff on QR payment acceptance comes down to two critical scenarios that will absolutely occur, probably within the first week.

The first is the screenshot scam. A customer shows the merchant a screenshot of a payment confirmation screen rather than the live confirmation. The screenshot might be from a previous transaction, or it might be fabricated entirely. The screen looks convincing — it has the right colors, the right logos, the right amount. But no money actually moved. The rule is simple and non-negotiable: the PSP notification or POS confirmation is the source of truth, never the customer's phone screen. If the merchant's device didn't receive a confirmation, the payment didn't happen. Train staff to wait for their own alert before handing over the food.

The second is the stuck pending transaction. The customer initiates payment, their screen shows "processing" or "pending," but no final confirmation arrives on either end. This can happen because of network latency, a bank system hiccup, or insufficient funds that the sending bank is slow to report. The instinct is to ask the customer to try again — but that risks a double payment if the first transaction eventually clears. The correct response is to wait a reasonable interval, check the merchant's transaction log, and if no confirmation appears, ask the customer to use an alternative payment method. Any stuck transaction can be investigated after the fact through the PSP's dashboard.

The Close-of-Day Routine

Every merchant accepting QR payments needs a close-of-day reconciliation process, even if it's simple. Export the day's transactions from the PSP app or dashboard. Compare the total to your sales records — whether that's a POS system, a notebook, or MakanKaki's order management platform. Flag any mismatches: missing payments, unexpected refunds, or duplicate credits from retried transactions. For a single hawker stall, this takes five minutes. For MakanKaki managing hundreds of stalls, it's an automated batch process that runs every night and surfaces exceptions for human review.

Getting Started: The Merchant Setup Path

Setting up QR acceptance isn't complicated, but it does require deliberate decisions made in the right order.

First, choose your acceptance provider. Depending on the market, this might be your existing bank, or a third-party PSP like Paytm in India, Mercado Pago in Brazil, or GrabPay in Southeast Asia. Compare not just fees but the quality of reconciliation tools and merchant support — because when a transaction goes sideways at 11:30 on a Saturday night, you need someone who picks up the phone.

Second, decide whether you need static or dynamic QR. If you're a single-counter operation with modest volume, static is fine. If you're processing orders through a digital platform — as MakanKaki's stalls do — dynamic QR with POS integration will save you hours of reconciliation headaches.

Third, secure the physical QR itself. A static QR code printed on regular paper will fade, get splashed with chili sauce, and eventually become unscannable. Laminate it. Better yet, mount it at an angle where customers can scan without picking it up — because a QR code that walks away in someone's hand is a QR code you have to reprint and re-register.

Fourth, train every staff member on the confirmation workflow. Not just the owner, not just the manager — everyone who hands food to a customer needs to know: wait for the notification, never trust the customer's screen, and know what to do when a payment hangs in pending.

Fifth, build your close-of-day reconciliation routine before you need it. The first week of accepting QR payments, run the reconciliation daily and compare against your records. Once you trust the process, you can automate or simplify — but start disciplined.

These operational details aren't glamorous. Nobody writes breathless headlines about close-of-day reconciliation routines. But they're what separates a merchant who trusts QR payments from one who abandons them after a week of confusion and unmatched transactions. And trust, once broken, is hard to rebuild.

Of course, operational discipline only protects against honest mistakes and routine confusion. It doesn't protect against the people actively trying to exploit the system. QR codes sitting in plain sight on every counter, encoding payment instructions anyone can read — that's a surface area for fraud that cards never had. Understanding those vulnerabilities, and the defenses being built against them, is where we turn next.

Security, Fraud, and Resilience

A QR code is just a picture. It sits on a countertop, taped to a wall, printed on a receipt — visible to everyone, readable by any camera. That openness is what makes QR payments so easy to deploy. It's also what makes them so easy to attack. The fraud patterns that matter here aren't the generic payment scams you'd find in any system. They're the ones that exploit the specific mechanics of how QR codes encode and transmit payment instructions.

The Four Attacks That Keep Operators Up at Night

The most low-tech and effective QR fraud is the sticker swap. An attacker prints a QR code linked to their own merchant account, then physically pastes it over a legitimate merchant's code. Every customer who scans it sends money to the wrong person. The merchant doesn't notice because they're not watching the code — they're watching the counter. The attacker doesn't need to hack anything. They just need a printer and some adhesive. In markets where static QR dominates, this is a real and recurring problem. Indonesia's QRIS ecosystem has dealt with multiple cases, and the pattern shows up everywhere static codes are used.

The screenshot scam works in the opposite direction. We touched on this in the previous section as an operational headache, but it's worth understanding the mechanics. The customer shows the merchant a fabricated payment confirmation — a screenshot of a successful transaction, sometimes edited from a real one, sometimes built from scratch. If the merchant relies on the customer's screen instead of their own notification, the fraud succeeds. This scales surprisingly well. Organized rings have reportedly used the technique across dozens of food stalls in a single night, exploiting the fact that busy merchants during peak hours barely glance at the screen being waved in front of them.

Payee misdirection is subtler. Remember the proxy systems from earlier in this chapter — phone numbers, email addresses, national IDs mapped to bank accounts? An attacker registers a proxy that looks almost identical to a legitimate one. Maybe it's a phone number one digit off, or an alias with a character substitution. Then they use social engineering — a fake invoice, a spoofed message — to get the victim to send money to the wrong identifier. Colombia's Bre-B team anticipated this pattern, which is partly why they invested so heavily in "this is not an app" messaging. If users understand the system is a feature inside their bank app, they're harder to redirect to a fake portal.

The fourth pattern is request-to-pay abuse. Systems like UPI and Pix allow merchants to send collection requests — essentially, "please approve this payment." An attacker sends a request disguised as a receipt or refund confirmation. The victim sees a notification, assumes it's routine, and taps approve. They've just authorized an outbound payment. India's UPI ecosystem saw enough of these that NPCI introduced friction — extra confirmation screens, cooling-off delays — specifically for inbound collect requests.

Mitigations That Actually Scale

No single defense stops all four attacks. What works is layering protections across the entire transaction flow.

At the confirmation stage, recipient verification is the strongest tool. When you scan a QR code, your app should display the registered merchant name before you authorize. If MakanKaki's QR resolves to "MakanKaki Pte Ltd" in your banking app, and a sticker swap redirects it to "J. Random Person," you have a chance to catch it. This only works if users actually read the screen — but it shifts the odds.

Transaction limits and velocity controls contain blast radius. Even if fraud succeeds, capping per-transaction amounts and flagging unusual patterns — ten payments in five minutes from different customers all to the same new account — lets the system respond before losses compound. Step-up authentication for larger amounts adds another gate.

For screenshot scams, the answer is merchant-side confirmation infrastructure — the soundbox devices and notification systems we discussed. If the merchant's own device confirms receipt, the customer's screen becomes irrelevant.

Dynamic QR codes with expiry address a different slice of the problem. A QR that's only valid for 60 seconds can't be photographed and replayed later. It can't sit on a sticker for weeks redirecting payments. The trade-off is complexity — someone has to generate and display fresh codes — but for higher-value transactions, it's worth it.

When the System Itself Is the Risk

Individual fraud is one problem. Systemic fragility is another. QR-based instant payment systems face a specific resilience challenge: every scan triggers a real-time status check. During a shopping festival or year-end sale, millions of customers scanning codes simultaneously means millions of concurrent status polls hitting the same infrastructure. Pix processes over 200 million transactions on peak days. QRIS volumes spike dramatically during Ramadan.

Capacity planning for these spikes is non-trivial. Rate limiting on status polls prevents a flood of "did it work yet?" queries from overwhelming the system. Idempotency keys — unique identifiers attached to each transaction attempt — ensure that if a customer scans twice because the first response was slow, the system doesn't process the payment twice. Duplicate detection catches the edge cases idempotency misses.

The unsexy truth is that resilience engineering matters more than fraud prevention for the long-term credibility of QR payment systems. A fraud incident hurts individuals. A system-wide outage during a national shopping event hurts the entire ecosystem's reputation.

Cross-Border QR and Future Outlook

Everything we've covered so far happens inside a single country. One central bank, one set of rules, one proxy directory. But people travel. Businesses trade across borders. And the question every QR payment ecosystem eventually faces is: can a tourist from Singapore scan a QR code in Jakarta and pay with their home bank app?

Bilateral Links Are Already Live

The answer, increasingly, is yes. Indonesia and Singapore launched QRIS-NETS QR linkage, allowing Singaporean visitors to scan Indonesian QRIS codes using their NETS-compatible apps. Indonesia and Malaysia did the same with QRIS-DuitNow QR, connecting two of Southeast Asia's largest instant payment ecosystems. The mechanics work roughly the way you'd expect: the foreign app scans the local QR, the transaction routes through a gateway that bridges the two domestic systems, and currency conversion happens in the middle.

These bilateral linkages work, but they don't scale elegantly. If you have five countries, you need 10 bilateral connections. Ten countries need 45. Twenty countries need 190. Every link requires its own legal agreement, technical integration, settlement arrangement, and dispute resolution process.

The Hub Model: Project Nexus

This is the problem the Bank for International Settlements' Project Nexus is trying to solve. Instead of connecting every country to every other country, Nexus proposes a central coordination layer. Each domestic instant payment system connects once to the Nexus platform, and gains access to every other connected system. Five countries need five connections, not ten. Twenty countries need twenty, not 190.

The BIS published its blueprint in July 2024, with first live connections targeted for the 2026–2027 window among an initial group of countries. The ambition is significant — a genuine multilateral instant payment network that works across currencies and regulatory regimes. Whether it achieves that ambition on schedule is an open question, but the architecture is sound and the political will, at least in Southeast Asia, appears real.

Five Trends to Watch

Beyond cross-border, several developments will shape where QR payments go next.

1. Recurring payments on instant rails are coming. Brazil's Pix Automático now lets users authorize standing payment instructions — subscriptions, utility bills, loan repayments — that execute automatically over instant payment infrastructure. This moves QR ecosystems from purely one-off transactions into territory currently dominated by direct debit and card-on-file — the pull-payment world of the next chapter. If it works at scale in Brazil, every other instant payment system will follow.
2. Merchant tooling is becoming a competitive battleground. Soundbox devices are just the beginning. Dynamic QR invoices that embed line-item detail, integrated loyalty point accrual, and POS system integrations that sync QR payments with inventory management — all of these are being built by fintechs competing for merchant adoption. The QR code itself is commoditized. The value is in the software wrapped around it.
3. Offline QR capability addresses the hardest deployment problem: connectivity. In rural Indonesia, in Brazilian favelas, in Indian villages where mobile signal drops in and out, a payment system that requires real-time connectivity will fail at the worst moments. Several ecosystems are experimenting with offline-capable wallets that can authorize limited-value transactions without a network connection, queue them locally, and reconcile when connectivity returns. It's technically difficult and introduces new fraud vectors, but it's essential for true financial inclusion.
4. Central bank digital currencies may eventually change what settles behind the QR scan. Several central banks — including Bank Indonesia with its Digital Rupiah explorations — are investigating whether a CBDC could reuse the same QR and proxy infrastructure that already works for bank-to-bank payments, while changing the underlying settlement asset from commercial bank money to central bank money. The user experience might not change at all. The plumbing underneath would be fundamentally different.
5. Finally, data governance and competition policy will determine who controls these systems. Proxy directories — the databases mapping phone numbers to bank accounts — concentrate extraordinarily sensitive information. Who can access that directory? Can fintechs query it on the same terms as banks? Can users port their proxy mappings? Can the directory operator use aggregate data for commercial purposes? These questions are already being contested in India and Brazil, and the answers will shape whether QR payment ecosystems remain open and competitive or consolidate around a few dominant players.

Where This Leaves Us

QR codes didn't reinvent payments. They didn't need to. What they did was strip away the expensive, proprietary hardware that kept digital payments locked inside wealthy economies and large merchants. A camera and a standard — that's all it took to bring hundreds of millions of people and businesses into the digital payment economy for the first time.

The hard problems aren't technical anymore. They're institutional: governance, interoperability, competition, resilience at scale. The countries that solve those problems will build payment infrastructure that lasts. The ones that don't will build fragile systems that work until they're tested.

Everything in this chapter moved money one way: you pushed it. In the next chapter, we flip the arrow — direct debits, mandates, and the machinery that lets a merchant reach into your account and pull.

Sources

Standards and Specifications

EMVCo, QR Code Payment Specification (QRCPS) — the global standard defining how payment data is encoded in QR codes, including merchant-presented and consumer-presented modes

Indonesia

Bank Indonesia, QRIS documentation — scheme rules, merchant guidance, and MDR tier structure for Indonesia's national QR standard

Bank Indonesia, Annual Meeting 2025 statistics — transaction volume and adoption figures for QRIS

Bank Indonesia, Payment Systems Blueprint 2025 — strategic roadmap for Indonesia's payment infrastructure including QR interoperability goals

Bank Indonesia, CBDC/Digital Rupiah white paper — exploration of central bank digital currency design and its relationship to existing QR and proxy infrastructure

MAS/BI joint announcements on cross-border QR linkages — bilateral agreements enabling QRIS-NETS QR and QRIS-DuitNow QR interoperability

India

NPCI, UPI product statistics (January 2026) — transaction volumes, value, and participant data for India's Unified Payments Interface

Government of India, zero MDR circular (UPI/RuPay) — regulatory decision eliminating merchant discount rates on UPI and RuPay transactions

Brazil

Central Bank of Brazil, Pix scheme regulations and Pix key documentation — rules governing Pix aliases (keys), participant obligations, and transaction processing

Central Bank of Brazil, Pix statistics and press materials — official adoption and transaction data for Pix

Central Bank of Brazil, Pix Automático documentation — specifications for recurring payment functionality on Pix rails

Mexico

Banco de Mexico, SPEI documentation and FMI reports — technical and regulatory documentation for Mexico's interbank payment system

Banco de Mexico, CoDi developer/merchant guide — specifications for Mexico's QR-based payment overlay on SPEI

Banco de Mexico, DiMo documentation and statistics — Mexico's rebranded and simplified digital payment platform

Colombia

Banco de la Republica (Colombia), Bre-B documentation and alias guidance — scheme rules and proxy identifier design for Colombia's instant payment system

Singapore

MAS, SGQR documentation — specifications for Singapore's unified QR code standard combining multiple payment schemes

International and Multilateral

BIS, Project Nexus blueprint (July 2024) — multilateral instant payment interconnection architecture and implementation roadmap

World Bank, QR code payments analysis — cross-country assessment of QR payment adoption, economics, and inclusion impact

ACI Worldwide/GlobalData, "Prime Time for Real-Time" benchmark — global comparison of real-time payment volumes and growth across markets