This is a product concept for someone who has sent money to the wrong UPI ID. I designed what happens after they notice the mistake: how the sender raises and tracks a request, and how the recipient responds.
My contribution
I defined the problem, prioritised features and wrote the requirements and sprint plan. AI tools helped with research and the prototype.
Start with the receipt
I put the recovery action on the payment receipt because it already has the transaction details. Those details carry into a prefilled request, reducing what the sender has to type.
The sender receives a case ID and a timeline showing the status and next step.
Give the recipient a way to respond
The recipient can return the full amount, offer a partial return or say that the payment was intentional. I included these paths because a recovery request needs an answer at the other end.
A suspected scam follows a separate fraud route. The recovery flow also checks whether a payment is eligible before raising a request.
Turn the screens into planned work
I broke the chosen features into nine user stories and 48 acceptance criteria, with a proposed nine-week delivery plan.
A return payment could expose the sender's phone number through their UPI ID, so the plan uses a masked name. I also added a separate Help entry: an ineligible payment still needs a route to support when the recovery button is hidden.
What is public to read and open
The public study contains the requirements, competitor comparison, clickable prototype and sprint plan. Personas and quotes are illustrative; this is an independent concept, with no PhonePe affiliation.
The prototype demonstrates the screens and choices. Bank integration, real-user interviews and a support-team review would be needed before it could process recovery requests.
