Who it's for
Two personas with the same problem: Ritika, a metro salaried user, and Sunita, a tier-2 shop owner who needs Hindi, a person to call and a flow that works on slow internet.
A product concept that lets a PhonePe user start recovery in one tap, lets the recipient return the money in one tap, and shows both of them exactly where the case stands.
When a user sends money to the wrong UPI ID, there is no undo. They have to deal with the recipient, their bank, the recipient's bank, NPCI and sometimes the RBI Ombudsman, with little idea who owns the case or what comes next.
Money can only come back if the recipient agrees, so every day of delay makes recovery less likely.
Two personas with the same problem: Ritika, a metro salaried user, and Sunita, a tier-2 shop owner who needs Hindi, a person to call and a flow that works on slow internet.
15 features benchmarked across Google Pay, Paytm, BHIM, NPCI and payment systems in the UK, EU, Australia, Brazil and the US. Full research with sources →
Every app shows the payee's bank name before paying, and routes complaints through NPCI's UDIR. But the dispute is a generic form, sometimes locked for 2 days, and the recipient returning the money stays voluntary.
The recipient gets a "Return payment" button, a one-tap full or partial return within 90 days. A contest button makes the receiving bank freeze the funds.
Report a mistaken payment within 10 business days and the money comes back, even without the recipient agreeing, if it's still there. Speed is everything.
The gap: no Indian app has a recovery flow built for wrong-payee mistakes, with an owner, a deadline and an easy way for the recipient to return the money.
A "Recover payment" button on every UPI receipt that sends a pre-filled recovery request in seconds, so users report while the money can still be traced.
The recipient gets a clear request with a one-tap "Return payment" button, so returning a wrong payment is easier than ignoring it.
A plain-language timeline showing who has the case, what happens next and by when, so users can see progress instead of chasing support.
| Opportunity | Reach | Impact | Confidence | Effort | Priority |
|---|---|---|---|---|---|
| One-tap Recover | High | High | High | Low | P0 |
| Easy Return | High | Med | High | Med | P1 |
| Live Tracker | Med | High | Med | High | P2 |
Users can raise a recovery request in one tap from any UPI receipt, with the payment details filled in automatically. The recipient gets a one-tap option to return the money, and both sides can follow the case on a live tracker from start to close.
Performance: request sent within 10 seconds; tracker updates within 1 minute of a bank update; works on 3G.
Quality: requests auto-filled and eligibility-checked; under 2% sent back for errors.
Reliability: one case per payment; no request lost if the app or network drops.
Secure: encrypted, stored in India, DPDP-compliant; returns need a UPI PIN and a real payment.
Transparency: every case shows owner, next step, deadline and final outcome.
Usability: 3 taps or fewer, no jargon, available in 5+ Indian languages.
Mock-ups of the core flow. Open the clickable prototype →
The PRD's P0 and P1 solutions turned into a backlog the team could start on Monday: user stories that pass INVEST, measurable acceptance criteria, sizing, and a week-by-week plan, all tracked in Jira and Trello. Live Tracker (P2) is held for a later release.
| # | User story | Size | Risk | Impact | Sprint |
|---|---|---|---|---|---|
| US1 | Sender sees a "Recover payment" button on an eligible receipt | S | 3 | 5 | 1 |
| US2a | Prefilled, locked request: no typing, no jargon | M | 3 | 5 | 1 |
| US2b | Case ID in 10 seconds, no duplicates on a network drop or double tap | L | 5 | 5 | 2 |
| US3 | Told which eligibility rule failed, and where to go instead | M | 2 | 2 | 2 |
| US4 | "This was a scam" goes to the 1930 helpline, never to the recipient | M | 3 | 5 | 2 |
| US5 | Recipient gets a safe request: amount, first name and date only | S | 2 | 2 | 3 |
| US6 | Recipient returns the full amount with their UPI PIN, sender masked | S | 4 | 4 | 3 |
| US8 | Recipient taps "This isn't a mistake" and the case goes to bank review | M | 4 | 2 | 4 |
| US7 | Partial return: send what you have, the case stays open for the rest | M | 4 | 3 | 4 |
Size: S = 1 week, M = 2 weeks, L = 1 month. Risk and Impact are scored 1–5. Each story carries six acceptance criteria, one per quality lens: Performance, Quality, Reliability, Security, Transparency, Usability.
| Story | W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 |
|---|---|---|---|---|---|---|---|---|---|
| US1 Recover button | ✔ | ||||||||
| US2a Prefilled request | ✔ | ||||||||
| US2b Case ID (critical path) | ✔ | ||||||||
| US3 Why it doesn't qualify | ✔ | ||||||||
| US4 Scam route | ✔ | ||||||||
| US5 Safe request | ✔ | ||||||||
| US6 Full return | ✔ | ||||||||
| US8 Dispute | ✔ | ||||||||
| US7 Partial return | ✔ | ||||||||
| Pilot readiness | ✔ |
Sprints 1–2 build One-tap Recover; Sprints 3–4 build Easy Return. Easy Return can't start until US2b creates cases, so US2b sets the length of the whole plan.
A return payment would have shown the sender's UPI ID, which often contains a phone number. Fixed by showing a masked name ("Ritika S."), with a spike planned to prove it can be built.
One story hid the Recover button on ineligible payments, while another needed users to tap it. Fixed with a "Help → I paid the wrong person" entry.
"Prefilled request + case ID" was sized XL. Splitting it into a screen (M) and a case service (L) exposed the critical path, and the plan went from 5 to 9 weeks.
A scam report must never contact the recipient. It goes straight to the 1930 helpline and cybercrime.gov.in, so scammers can't use the flow to pressure people.
Stories, acceptance criteria, sizing and learnings on GitHub →