Blog
Walking Through a UPI Transaction: Eight Hops, Six Failure Modes
A UPI payment looks simple from the outside: tap, PIN, done. Underneath it are eight hops between tap and confirmation, and six distinct ways the flow can break. This is an interactive walkthrough of what's happening, and what a PM would build for each failure mode.
The Question Nobody Answers Well
Every fintech PM interview eventually asks some version of: "Walk me through a UPI transaction."
The short answer, user enters a UPI ID, enters a PIN, money moves, is correct. It's also the surface of something with eight moving parts underneath it, each one a place where the transaction can fail in a different way, with a different thing showing up on the user's screen. That's the part worth understanding: not just that the payment works, but what happens when it doesn't.
The Intent Flow, Actually
A UPI transaction has two distinct flows depending on how it's initiated. The one most PMs skip over is the Intent flow, used when you scan a QR code at a merchant terminal instead of typing in a VPA. It's also the busier of the two: it's the flow behind most peer-to-merchant UPI payments in the country.
Here's what actually happens between tap and confirmation:
- User taps Pay, the merchant app fires a UPI Intent.
- The intent resolves to a registered UPI app, Google Pay, PhonePe, Paytm, whichever the user has set as default.
- The app validates the payee VPA and sends a collect request to NPCI.
- NPCI checks the user's daily transaction limit and routes the debit request to the issuing bank.
- The issuing bank authenticates the UPI PIN, a cryptographic key stored on the device and never transmitted in plain text, and checks the balance.
- The debit executes. Money actually leaves the user's account at this point.
- The payee PSP credits the merchant's account over IMPS rails.
- The merchant is notified and the user sees the success screen.
Eight hops. Every one of them is a place something can go wrong.
See It Break
Reading the list is one thing. Watching where it snaps is another.
Click the highlighted node to move through the flow. Steps marked with a small dot have a failure branch, once you're on that step a button appears below the diagram showing what breaks technically, what the user sees, and what a PM would ship to handle it. Six failure modes are mapped in. None of them are edge cases; each is a class of incident every fintech PM eventually runs into.
The Three Worth Knowing Before You Click
The simulator covers all six. These three are the ones with the biggest blast radius, worth reading even if you never touch the diagram.
Network drop, post-debit. The user's connection dies after the debit instruction goes out but before the confirmation comes back. The debit may have already succeeded on the backend; the app just doesn't know it yet. What the user sees ranges from nothing to a flat "Payment Failed," and that's the real problem: this isn't a payment failure, it's a reconciliation failure. The fix isn't a better error message. It's a reconciliation job that runs every five minutes, cross-referencing NPCI's transaction records against the merchant's order state, plus a proactive push notification so the user isn't left refreshing the app to find out.
Payer PSP Timeout. The app the user picked, Google Pay, PhonePe, whichever, doesn't hear back from NPCI within the mandate window. All the user sees is a spinner, or "Payment Pending," with nothing confirming whether the money moved. The fix is progressive disclosure on a timer: auto-poll at T+30s, surface "we're checking on this" with a reference number at T+60s, put an explicit "Check Status" button in front of them at T+90s. What you never do is show "Failed" before the backend confirms it.
Issuing Bank Server Down. This one lands after the user has already entered their PIN, which is what makes it the worst version of this failure: they did everything right and still get "Transaction Failed" 20 to 30 seconds later. The bank's core system is down, overloaded, or mid-maintenance, and there was nothing the user could have done differently. The fix has to happen before PIN entry, not after: a rolling 15-minute health check on each bank via NPCI's status feed, and a warning shown before the user selects a bank that's currently failing above a threshold.
The Interview Signal
Explain the above and an interviewer learns three things at once: you've read the NPCI spec, you think in failure modes by default, and you know the gap between what the user sees and what the system is doing.
That gap is where most payment UX problems live. Closing it is the difference between a PM who ships payment features and one who ships payment features people trust.
What I'd Build
The highest-leverage fix for UPI reliability isn't anywhere in the happy path. It's a client-side transaction state machine with real states: Initiated, Pending, Confirmed, Failed, Reconciling.
Most apps today only have two: Success and Failed. The missing states are exactly where trust breaks. A "Reconciling" state with honest copy, something like "We're checking on this, you'll know in two minutes," beats a fake "Processing" spinner every time.
Where This Doesn't Reach
This piece, and the simulator, cover the Intent flow only. The Collect flow was deprecated by NPCI in February 2026. AutoPay (UPI mandates) runs on a separate flow with its own failure modes, and BBPS payments use a different rail entirely. Intent is the right place to start because it's the dominant flow for peer-to-merchant payments, which is where most fintech PM work lives.