You pay at a shop with UPI. The money leaves your account, and the shopkeeper says it never arrived. The screen says Pending. Now turn that into an interview question: "What should the app show here, success or failure? And if the user taps Pay again, how do you stop a double debit?" It sounds like a question about UPI. It is really a question about how any payment system handles a timeout.
The common answer is too hasty
Most people say: show failed and refund the money. It sounds safe. To see why it isn't, follow one payment.
- The app sends a message; it never holds your money.
- Your bank debits your account. The debit happens first.
- NPCI's UPI switch asks the shop's bank to credit the money and reply.
- The shop's bank credits it and replies, and the success travels back to your phone.
Now suppose the reply in step 4 doesn't arrive in time. There are two possibilities: the shop's bank credited the money and only the reply was lost, or it never credited it. From the outside, both look exactly the same.
Why neither guess works
- Declare failure and refund, but the credit happened: the shop has the money and you got it back too. The same payment has been paid out twice.
- Declare success, but the credit never happened: the shopkeeper is left with nothing.
So the honest answer is a third state. Pending means "we don't know yet". UPI's own rules moved this way: an NPCI circular from 2017 stopped treating an unanswered credit as declined and started treating it as "deemed approved" until it is resolved.
Ask about the same transaction, don't repeat it
Think of ordering food by phone. You have already paid, you read out order number 123, and the call drops. If you call and order again, you pay twice. The sensible move is to call back and ask: "What happened to order 123?"
UPI does the same. Every payment carries its own transaction ID, and the switch asks the shop's bank about that same ID a few times, within a time limit. Asking is safe because a status check only reads; no money moves.
If a payment system ever has to re-send the payment itself, it re-sends it with the same ID, and the receiving side remembers which IDs it has already applied, so it happens only once. That property is called idempotency. Stripe's engineering blog puts the underlying problem plainly: "The call could succeed, but the connection break before the server can tell its client about it."
Tapping Pay again is different. It creates a new transaction with a new ID, which is a genuine second payment. That is why apps tell you to wait instead of paying again.
How it finally ends
If the status checks still get no answer, the payment stays Pending until reconciliation: after settlement, the shop's bank matches its own records and either confirms the credit, which makes the payment a success, or returns the money. Refunds come out of that check, not out of a timer running out. The RBI sets the outer limit:
| Paid to | Must be resolved by | Compensation if late |
|---|---|---|
| A shop (person to merchant) | T+5 days | ₹100 per day |
| A person (person to person) | T+1 day | ₹100 per day |
RBI circular DPSS.CO.PD No.629/02.01.014/2019-20, 20 September 2019, effective 15 October 2019. T is the calendar date of the transaction.
The answer to give
A timeout isn't a failure. It's Pending.
Say it like this: "I'll treat a timeout as unknown, not failed. Every payment gets a unique ID. I'll check its status with that ID, make retries idempotent with the same ID, and refund only after reconciliation confirms the money never arrived."
And if it ever happens to you as a user: don't pay again, note the UPI reference number, and if the deadline passes, raise a complaint on that transaction in the app. If it isn't resolved within 30 days, you can go to the RBI Ombudsman.
Sources: RBI, TAT harmonisation circular (2019); Stripe, Designing robust and predictable APIs with idempotency; Oracle, India UPI bank integration guide; PhonePe Business, transaction status and refunds; Outlook Money, NPCI chargeback rule (2025).