Stablecoin Scan-to-Pay Is Not a Payment Problem. It's a Payout Problem.

Every month, a new wallet announces "crypto payments." The pitch is always the same: spend your USDT at any store.

But step into any shop in Ho Chi Minh City, Bangkok, or Manila. The merchant has a QR code on the counter - VietQR, PromptPay, QR PH. It's connected to their bank account. They have no idea what a stablecoin is, and they don't need to.

So when a user scans that QR with a crypto wallet and the merchant receives Vietnamese dong in their bank account three minutes later — what actually happened?

It wasn't a crypto payment. It was a fiat payout, funded by crypto.

This distinction matters. It changes how you architect the system, where the hard problems are, and ultimately who wins in this space.

The QR rails already exist

Across APAC, QR code payments are not an experiment — they are the default. Over the past five years, countries have rolled out national QR standards built on top of the EMVCo specification, a global standard that defines how payment data is encoded into a QR code.

The important thing: these QR codes all follow the same underlying structure. A Tag-Length-Value encoding that contains the merchant's bank account, the transaction amount, currency code, and merchant identifier. Different countries wrap it differently, but the bones are the same.

This means a single QR parser, built once, can decode merchant payment data across Vietnam, Thailand, Singapore, Brazil, the Philippines, and any other market that follows the EMVCo standard.

That's the entry point. The QR rails already exist. Hundreds of millions of merchants already display them. The question is: how do you plug a crypto wallet into those rails?

The execution model

Here's what happens — step by step — when a user pays a street vendor using stablecoins through a scan-to-pay system:

Why this is a payout, not a payment

The language matters because it changes the architecture.

If you think you're building a "crypto payment gateway," you're trying to get merchants to accept crypto. That means merchant onboarding, new terminals, new settlement flows, compliance education — all the friction that has stalled crypto payments for a decade.

If you think you're building payout infrastructure, the picture flips entirely. The merchant doesn't need to know crypto exists. They receive a bank transfer. Your job is to collect stablecoins on one side and deliver fiat on the other.

This is the same structural insight that made Wise (formerly TransferWise) work. They didn't try to convince banks to change how they process transfers. They built a payout layer on top of existing bank rails. Stablecoin scan-to-pay follows the exact same playbook — but with crypto as the funding source instead of a foreign bank account.

Two sides, one bridge

The system has a clean separation:

On the left, the user lives in the crypto world — holding stablecoins, signing on-chain transactions. On the right, the merchant lives in the fiat world — receiving bank deposits in local currency. The payment provider sits in the middle, bridging both sides.

Neither side needs to understand the other. That's the entire point.

Where the hard problems are

If blockchain is just the rail, what's actually difficult?

QR parsing across national standards. VietQR, PromptPay, SGQR, PIX — they all follow EMVCo, but each wraps it differently. Country-specific merchant ID formats, bank routing structures, and currency encoding all need to be handled. A parser that works for Vietnam won't automatically work for Thailand without adaptation.

Real-time FX at payment speed. The exchange rate must be locked at the moment the user confirms. If the rate slips between QR scan and order creation, someone absorbs the loss. Rate locking, slippage management, and spread calculation are treasury problems as much as engineering problems.

Fiat payout speed and coverage. This is the real moat. Collecting stablecoins on-chain is the easy part — Solana settles in seconds, EVM in minutes. The hard part is pushing fiat to a merchant's bank account in Hanoi or Cebu or Chiang Mai within minutes, not hours. That requires banking relationships, local payment rail integration, and liquidity in every target currency.

From the merchant's perspective

This is perhaps the most elegant part of the model. Consider the merchant — a coffee shop in District 1, Ho Chi Minh City. They have a VietQR code printed on the counter, linked to their Vietcombank account.

A customer walks in, scans the QR code with a crypto wallet, and two minutes later the merchant gets a push notification from Vietcombank: +450,000 VND received. From a domestic bank transfer. That's all they see.

They don't know the customer paid with USDT. They don't know a blockchain was involved. They don't care. The money is in their bank account, in dong, settled via the same rails they've always used.

This is why the model scales: adoption is bottlenecked only on the user side — how many people hold stablecoins and use wallets that support scan-to-pay. The merchant side is pre-solved. Every QR code in every shop in every supported country is already a valid payment endpoint.

What this means for builders

If you're building in the stablecoin payment space, the framing determines the architecture:

Building a "crypto payment gateway" means you're fighting a merchant adoption problem that hasn't been solved in ten years of trying. You're asking millions of merchants to understand, accept, and settle crypto — an uphill battle against inertia, regulation, and education.

Building payout infrastructure means the merchant side is already solved. Your QR parser plugs into hundreds of millions of existing endpoints. Your challenge is narrower and more tractable: build the fastest, most reliable fiat payout network across target markets.

Blockchain is just the rail. The QR codes already exist. The merchants are already there.

The race is for fiat last-mile.

This article is an independent research overview of the stablecoin scan-to-pay model as it's emerging across APAC markets. The execution model described is generalized and not specific to any single provider.