UPI anatomy: how real-time payment rails work

A UPI payment feels like one atomic action. You scan, you type a PIN, and two seconds later both phones say it worked. Under that two seconds sit seven parties, a central switch, two separate bank ledger writes, and a settlement that will not actually happen for hours.

That gap is the whole design. Real-time payment rails are not "money moves instantly." They are "the promise moves instantly, and the money follows on a schedule." Once you internalize that split, most of the weird behavior in real-time rails (deemed transactions, reversal windows, net debit caps, penalty clauses) stops being weird and starts being the obvious consequence of a deliberate trade-off.

UPI is the largest working example of that trade-off, so it is the best one to dissect. Here is how it is actually wired.

What a real-time payment rail actually is

A real-time retail payment rail has three properties that separate it from a card network or a batch transfer like ACH or NEFT:

1. Push, not pull. The payer's bank initiates the debit. There is no merchant-initiated pull against a stored credential, so there is no "authorize now, capture later" step and no chargeback in the card sense.
2. Irrevocable and near-instant confirmation. Both parties get a final answer in seconds, and a successful payment cannot be unilaterally clawed back by the payer.
3. Deferred net settlement between the banks. The interbank money movement is batched and netted, then posted through the central bank.

Property 3 is the one everyone forgets. It is also the one that makes properties 1 and 2 affordable. If every ₹40 chai payment required a real gross transfer between two banks through the central bank, the rail would collapse under its own settlement volume.

Why UPI is the reference implementation

UPI runs at a scale that forces every one of these design decisions into the open. It cleared 23.2 billion transactions worth ₹29.9 trillion in May 2026, which works out to roughly 738 million payments a day, and it accounts for close to half of all real-time payment volume on the planet.

At that volume, an architecture that is merely "correct" is not enough. It has to be correct while degrading gracefully, because a 1% failure rate is 7 million broken payments a day.

The parties in a single tap

The mental model most engineers carry ("my app talks to my bank") is wrong by about five hops. A UPI transaction involves:

• The payer's app (TPAP). PhonePe, Google Pay, Paytm. It collects intent and captures the PIN, but it never sees the PIN in cleartext. Entry happens inside an NPCI-certified component the app cannot read.
• The payer's PSP. A sponsor bank that issues the @handle and signs requests. The suffix in you@ybl identifies the sponsor bank, not the app you tapped.
• The payer's (remitter) bank. The only party that can decrypt the PIN, check the balance, and debit the account.
• The NPCI switch. The central router. It resolves addresses, sequences the debit and credit, and keeps the authoritative record of what happened.
• The payee's (beneficiary) bank. Credits the receiving account.
• The payee's PSP and app. Relay the outcome to the merchant or recipient.

Notice what the switch does not do: it never holds funds. It routes messages and computes obligations. The money never sits in an NPCI account mid-flight.

Anatomy of a transaction: debit first, credit second

The API surface is XML over HTTPS, and the core message is ReqPay, with RespPay carrying the outcome back. Address resolution runs through ReqValAdd, and status checks through ReqChkTxn. The ordering is the interesting part.

Step 4 is the load-bearing ordering decision. Because credit is strictly conditional on a confirmed debit, the rail can never create money out of a partial failure. It can only strand it, which is a recoverable problem. That is the same invariant a double-entry ledger enforces on every fintech app: you would rather have a suspense balance you can reconcile than a credit with no matching debit.

Authorization is not settlement

Here is the split, stated plainly.

Authorization is the payer's bank saying "this PIN is valid, this balance is sufficient, I have debited the account." It happens in step 3, in about a second, per transaction.

Settlement is the actual movement of funds between the two banks. UPI runs 10 settlement cycles per business day between 9 AM and 9 PM, plus two dedicated dispute cycles (DC1 running midnight to 4 PM, DC2 running 4 PM to midnight) that NPCI split out from the authorized cycles in November 2025 so that chargebacks and reversals stop clogging the main path.

In each cycle NPCI computes a net position per bank, not a per-transaction transfer. If Bank A's customers sent ₹900 crore to Bank B's customers and Bank B's customers sent ₹850 crore back, one ₹50 crore transfer settles both directions. Those net positions post through the RBI's RTGS system, with the central bank holding the settlement accounts.

So for a window of up to several hours, the payee's bank has credited a customer against money it has not yet received. That is not sloppiness, it is the deliberate extension of intraday credit that makes the rail economically viable. It also means the rail carries genuine settlement risk, which is why participation comes with collateral and net debit cap requirements rather than being open to anyone with an API client.

Where it actually breaks

Three failure classes matter, and they are not equally your problem.

Business declines (BD) are the user's side: wrong PIN, insufficient balance, per-transaction or daily limit hit. NPCI's circular OC-149 asks banks to keep these under 5%, and in practice they run near 1 in 10 payments. You cannot engineer these away, only reduce them with better UX (a pre-flight balance hint, and copy that makes clear the UPI PIN is not the ATM PIN).

Technical declines (TD) are infrastructure: bank server timeouts, switch overload, a core banking system that folds under a festival spike. The target is under 1%, and the ecosystem has dragged this from 8-10% in 2016 to roughly 0.7-0.8% today. Blended merchant success rates land in the 92-96% range once BD is included.

Deemed transactions are the interesting one, and the reason this article exists. A debit succeeded but the credit confirmation never came back. The payer's money is gone and nobody has told anyone anything definitive.

The rail resolves these itself. NPCI reconciles deemed transactions and posts a verdict, either credit confirmed or debit reversed. For P2P transfers the reversal is guaranteed within one day, and a bank that misses the window owes the customer a per-day penalty. Merchant payments take a few days longer.

For your system, a deemed transaction is a state, not an error. It needs its own status in your model, distinct from both success and failure, and it needs to be reconcilable when the verdict arrives. This is exactly the class of problem a reconciliation engine has to survive: a payment whose true outcome is known to the network before it is known to you.

The other half of the defense is on the write path. If your retry logic can resubmit a payment whose outcome is merely unknown, you will eventually double-debit a real customer. Idempotency keys on your payment APIs are what make the difference between "the network was slow" and "we charged them twice."

What to take from this if you are building a rail

You are unlikely to build a national switch. You are quite likely to build something that sits on one, or that copies its shape for a closed-loop wallet, a marketplace payout system, or an internal transfer product. The transferable decisions:

Separate authorization from settlement in your own model, explicitly. Two different objects, two different lifecycles, two different reconciliation processes. Teams that model a payment as one row with a status column discover the problem the first time settlement disagrees with authorization.

Order your writes so the failure mode is recoverable. Debit before credit. A stranded debit is a support ticket. A phantom credit is a loss.

Design the three-way outcome from day one. Success, failure, and unknown. Unknown is not a transient state you can code around later, it is a permanent citizen of any distributed money system, and every downstream consumer (ledger, notifications, support tooling, accounting export) needs an answer for it.

Net where you can. Netting is not an optimization you bolt on at scale. It changes your liquidity requirements, your counterparty exposure, and your collateral math, so it belongs in the design from the start. The same logic drives batching in much smaller systems, including the sub-cent agent settlement patterns where per-transaction settlement costs more than the transaction.

Assume bursts, not averages. 738 million payments a day is the average. Diwali is not. Build for the 10x minute, not the mean hour.

The elegance of UPI is not that it is fast. Plenty of things are fast. It is that it made a clean, honest cut between the part that has to be instant (the user's answer) and the part that does not (the banks' money), and then engineered each side to its own requirements. That cut is the reusable idea.

If you are designing a payment rail or untangling one that has outgrown its original model, our team does this work end to end; see how we approach payment rails development, or get in touch and tell us what is breaking.