← Back to Blog
•3 min read

Walking Through a UPI Transaction: Nine Hops, Six Failure Modes

FintechUPIPM Craft

The Question Nobody Answers Well

Every Fintech PM interview has some version of this question: "Walk me through a UPI transaction."

Most candidates say: "The user enters a UPI ID, enters their PIN, and the money transfers." That answer is not wrong. It is just completely useless as a signal of PM depth.

Here is what the question is actually asking: do you understand the infrastructure well enough to know where it breaks, what the user experiences when it breaks, and what you would build to handle that?

The Intent Flow, Actually

A UPI transaction has two distinct flows depending on how it is initiated. The one most PMs miss is the Intent flow — used when you pay via a QR code at a merchant terminal.

Here is what actually happens:

  1. The merchant's app generates a UPI Intent URL containing the payee VPA, amount, and transaction reference.
  2. The user's device resolves this intent to a registered UPI app (Google Pay, PhonePe, Paytm, etc.)
  3. The selected app sends a collect request to the Payer PSP.
  4. The Payer PSP forwards the request to NPCI's switch.
  5. NPCI routes the debit request to the Issuing Bank.
  6. The Issuing Bank authenticates via UPI PIN (stored as a cryptographic key on the device, not transmitted in plain text).
  7. NPCI sends a credit request to the Payee PSP.
  8. The Payee PSP credits the merchant's account.
  9. Settlement happens in near-real-time via IMPS rails.

Nine hops. Each hop is a failure surface.

Where It Breaks (And What A PM Does About It)

The most common failure points, in order of frequency:

Issuing Bank timeout: The bank's server takes too long to respond to NPCI. The transaction shows as "Pending." From the user's perspective: money may or may not have left their account. PM response: implement a status polling mechanism at T+30s, T+2min, T+5min. Surface the status clearly. Never leave a user in ambiguous "Pending" state beyond 5 minutes without an explicit update.

PSP degradation: One PSP handles millions of transactions. During peak load (salary credit days, festival sales), PSP failure rates spike. PM response: monitor PSP health in a rolling 15-minute window. If failure rate exceeds threshold, surface alternative payment methods proactively — before the user attempts and fails.

Network drop post-debit: The user's internet drops after the debit instruction is sent but before the response is received. The transaction may succeed on the backend but the app never gets the confirmation. PM response: mandatory reconciliation check on app resume. Never show "failed" without confirming with the backend.

The Interview Signal

When a candidate explains the above, the interviewer knows three things: they have read the NPCI spec, they think in failure modes, and they know the difference between what the user sees and what the system is doing.

That gap — between UI state and system state — is where 90% of payment UX problems live. Understanding it is the difference between a PM who ships payment features and a PM who ships payment features that users trust.

What I Would Build

The single highest-leverage intervention for UPI reliability is a client-side transaction state machine with explicit states: Initiated → Pending → Confirmed → Failed → Reconciling.

Most apps today have two states: Success and Failed. The missing states are where user trust breaks.

A "Reconciling" state with honest copy — "We're checking on this. You'll know in 2 minutes." — outperforms a false "Processing" spinner every time.

← Back to Blog