The article argues UPI isn't magic but a very deliberate design where NPCI sits as a government-adjacent switch in the middle of every transaction. By standardizing the rails and forcing all PSPs and banks to interoperate through one directory, competition happens at the UX layer while settlement stays uniform and near-instant.
The piece makes concrete that a VPA like yourname@okhdfcbank is just a routing key that maps via NPCI's central directory to an underlying account plus preferred PSP. This indirection means users never handle account numbers or IFSC codes, and can switch apps or banks without changing their public identifier.
The article highlights that the four-to-six-digit UPI PIN is verified inside the bank's hardware security module rather than in the PSP app. This means Google Pay, PhonePe, and others never see or store credentials — the trust boundary stays with the bank, which is what makes it safe for dozens of third-party apps to ride the same rails.
The article notes UPI now clears more transactions by count than Visa and Mastercard combined while charging end users nothing for P2P transfers. The implicit argument is that treating payment rails as public infrastructure — rather than a profit center — unlocks volumes and use cases (chai-stall QR payments) that fee-based networks structurally can't reach.
A long-form breakdown of UPI's transaction anatomy hit the top of Hacker News this week, walking through what actually happens between the moment you scan a QR code at a chai stall and the moment the merchant's phone chirps. The piece — from Time Series of India — is the kind of engineering write-up the UPI ecosystem has quietly needed for years: not a policy brief, not a fintech puff piece, but a plumbing diagram.
The headline numbers are familiar by now. UPI, the Unified Payments Interface built by the National Payments Corporation of India (NPCI) and launched in 2016, is now clearing on the order of 15 billion transactions per month — more than Visa and Mastercard combined by count, though not by value. It runs at effectively zero cost to end users for peer-to-peer transfers, settles in seconds, and is embedded in everything from Google Pay and PhonePe to WhatsApp and dozens of bank apps.
What the article makes concrete is that none of this is magic — it's a very deliberate architectural choice to put a single, government-adjacent switch in the middle of every transaction and let the banks and apps compete on everything except the rails themselves.
Strip UPI down and you get four actors: the payer's PSP (the app you tap in — GPay, PhonePe, Paytm), the payer's bank, the payee's PSP, and the payee's bank. The NPCI switch sits in the middle. The Virtual Payment Address — `yourname@okhdfcbank`, `9876543210@ybl` — is just a routing key. It maps, via NPCI's central directory, to an underlying bank account plus a preferred PSP. Nothing about the VPA itself moves money.
When you scan a QR, the payer PSP builds a request, signs it, and hands it to the NPCI switch. The switch resolves the payee VPA to a bank account, forwards a debit authorization to the payer's bank, gets back a signed OK (gated by the four-to-six-digit UPI PIN, which is verified inside the bank's HSM, not the app), and simultaneously fires a credit instruction to the payee's bank. Both legs must succeed or the whole thing rolls back. Settlement between the banks themselves is deferred and netted through RTGS in batches — you don't wait for that. The user-visible "success" is really "the switch says both legs are authorized."
That deferred-net-settlement trick is the single most important design decision in UPI: users get sub-second confirmation, banks get to settle in bulk, and NPCI absorbs the intraday counterparty risk. It's the same shape as card networks, but with a public-utility switch instead of Visa, and with bank accounts instead of a card PAN as the underlying instrument. That's why UPI can be free — there's no interchange to fund, because there's no card scheme to pay.
The piece is also honest about where the model bends. Every request goes through NPCI. Every. Single. One. When the switch degrades — and it has, notably during festival-season spikes — the whole country's retail payments degrade with it. Success rates published by NPCI hover in the high 90s but the tail is where it hurts: a 1% failure rate on 15 billion transactions is 150 million failed payments a month, most of which materialize as "money debited, not received" limbo that has to be reconciled T+1 or later. The UX papers over it with automatic reversals, but the plumbing is doing real work behind the scenes.
There's a second tension the article gestures at: PSPs make no money on the core transaction. MDR (merchant discount rate) is zero on UPI P2M by regulation. Google Pay, PhonePe, and Paytm together handle north of 85% of volume and effectively subsidize the rail in exchange for distribution, using UPI as a top-of-funnel for lending, insurance, and commerce. That's a subsidy model, not a business model, and it's the load-bearing assumption underneath every rosy UPI stat you've ever read.
If you build payments anywhere — Brazil's Pix, the EU's SEPA Instant, the US's FedNow, or a private rail inside a super-app — UPI is the reference implementation to read before you write a single line of code. A few concrete lessons:
Put the identity layer above the account layer. The VPA abstraction means users can change banks, apps, or phone numbers without their payment address breaking. Your equivalent is: don't force counterparties to know your customers' account numbers. Route on a stable handle, resolve at the switch. Pix does this with `chaves`; FedNow doesn't, and it shows.
Authorize online, settle offline. UPI's "instant to the user, netted to the bank" split is the only way to hit sub-second confirmation without asking every bank to hold real-time liquidity buffers on every counterparty. If you're designing an instant rail, decide up front which party eats the intraday risk — in UPI it's NPCI, backed implicitly by the RBI. Someone has to.
Make the PIN the bank's problem, not the app's. The UPI PIN never touches the PSP in cleartext; it's captured by an NPCI-controlled keyboard library, encrypted with the issuer bank's public key, and verified inside the bank. That's why a compromised PSP app can leak transaction metadata but not authorize a payment. If you're building a wallet, copy this pattern — separating consent capture from consent verification is the difference between a fraud incident and a full compromise.
Understand the subsidy. If your business model requires the rail itself to be profitable, UPI is not the shape you want — it works precisely because the government decided the rail is infrastructure and the apps monetize adjacent products. Pick a side deliberately.
The interesting frontier for UPI now is cross-border — the NPCI-Singapore PayNow linkage went live in 2023, UAE and France have followed, and there's an active push into Southeast Asia. Each linkage forces the switch to negotiate FX, sanctions screening, and dual regulatory oversight in real time, which is a different animal from domestic INR-to-INR. Whether the same central-switch model scales across sovereigns, or whether it fragments into a bilateral mesh of NPCI-to-Pix, NPCI-to-FedNow bridges, is the question worth watching. For engineers, the takeaway is smaller and more useful: the boring architectural choices — a central switch, a stable identity layer, deferred net settlement, bank-side PIN verification — are what make the flashy numbers possible. Copy those before you copy the UX.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.