QR Code Payments Decoded: 4 Systems, 6 Institutions, and the Async Architecture Behind Every Scan

Step 1: Authentication — Prove You Are You Before the Scan

The first step of QR code payment is not scanning; it is card binding. Third-party payment companies must verify your right to use the bank card using five factors: name, ID number, bank card number, and mobile number (four static pieces of data the bank already holds) plus a one-time SMS verification code sent to your registered mobile — the only dynamic factor. The flow runs: you submit data → bank sends SMS → you return data + code to the third party → third party forwards to bank for confirmation. On success, the bank returns a Token. All subsequent account operations by the third party use this Token, eliminating repeated verification.

Step 2: Cross-Bank Transfer — Seven Hops from Your Bank to the Third Party

After binding and scanning, funds do not jump straight to the third party. They traverse a precise cross-bank mechanism involving two core roles: the clearing institution (UnionPay or NetsUnion) and the central bank.

Daytime: The clearing institution only records transactions — it logs debits at the payer's bank and credits at the payee's bank, but no actual money moves between banks.

Nighttime netting (轧差): The clearing institution calculates net positions. Example: Bank A owes Bank B 3 million; Bank B owes Bank A 2.8 million. After netting, Bank A pays only 200,000 to Bank B.

Central bank settlement: The central bank adjusts deposit reserves — lowering Bank A's reserve and raising Bank B's. This is the moment money truly changes hands.

The essence of cross-bank transfer is asynchronous daytime recording, end-of-day batch netting, and a single central-bank settlement. Netting is the financial system's answer to high volume: not every message is processed instantly; they are batched and settled in aggregate.

Step 3: Foreign Exchange — RMB to USD via Four Accounts and Two Payments

Funds now sit in the third party's account as RMB, but the overseas merchant needs USD. Because RMB is subject to exchange controls, conversion must go through a qualified bank (the "FX provider bank").

The third party holds two accounts at the FX bank: an RMB account and a USD account. The FX bank maintains corresponding RMB and USD liquidity pools.

One FX transaction touches four accounts with two payments: (1) RMB moves from the third party's RMB account into the FX bank's RMB pool; (2) USD moves from the FX bank's USD pool into the third party's USD account.

Cost and timing constraints: FX trades incur per-trade fees and settle T+1 (funds arrive the next business day). Therefore, third parties do not buy FX per transaction; they pre-stock a large USD inventory and replenish only when inventory drops below a safety threshold. If the FX bank's USD pool runs dry, the wholesale interbank FX market — where global major banks exchange large fixed-rate deposits — steps in to provide deeper liquidity and ultimately sets the exchange rate.

Full Chain: From Scan to Merchant Receipt

User scans QR → third party initiates payment with Token → payer's bank debits (async) → clearing institution records → end-of-day netting → central bank settles reserves → third party receives RMB → FX conversion via FX bank (RMB to USD) → international clearing network → merchant's bank receives USD.

Almost no step in this chain returns a synchronous result. The user app must poll the backend for payment status, and banks push notifications when processing completes. This push-pull asynchronous pattern is standard in financial systems.

Why Asynchronous? Peak Shaving and Core Protection

Financial systems face extremely uneven user activity distributions. Asynchronous message architectures buffer all requests and process them gradually, preventing traffic spikes from overwhelming core systems.

Therefore, when designing systems that handle funds, two capabilities are mandatory — not optional: a status query interface and a message push mechanism. These are table stakes for financial-grade architecture.

Key Concepts Cheat Sheet

Authentication = 5-factor verification (4 static + 1 dynamic) → obtain Token

Cross-bank transfer = clearing institution daytime booking + end-of-day netting + central bank settlement

Foreign exchange = 4 accounts, 2 payments + T+1 time cost

Full chain = asynchronous throughout, push-pull combined for state retrieval

Closing Thoughts

The fundamental difference between financial architecture and other internet architectures is not the middleware or database choice; it is that financial systems embrace uncertainty from the ground up. They never assume any step can return an immediate result. Every step is designed with retries, reconciliation, and fallbacks.

This mindset applies beyond finance. Any scenario demanding high data consistency deserves a re-examination through this asynchronous design lens.