[ GPay - Case study / 2026 ]
I paid for everything with UPI, then found my bank account nearly empty with no idea where the money went. That became this project: what if Google Pay had what I needed? Label each payment in one tap, and see where the month went.
Three of the twenty-three. See the whole application
[ GPay - The problem / 01 ]
Which is why someone who pays for everything by UPI can still finish the month with no idea what they paid it for.
Payment apps own the transaction. Tracking apps own the insight.
Scored during a five-app teardown. The pattern is consistent, and it is the whole reason this concept goes inside a payment app rather than beside one: the apps people pay with do not report, and the app that reports is not one people pay with.
| Capability |  Google Pay |
 PhonePe |
 Paytm |
 Cred |
 Money Manager |
|---|---|---|---|---|---|
| UPI transactions | |||||
| Bill payments | |||||
| Manual payment notes | |||||
| Bill reminders | |||||
| Expense categorisation | |||||
| Weekly / monthly summaries | |||||
| Exportable reports |
Scroll the table sideways to compare all five apps.
[ GPay - The research / 02 ]
Real-time interviews with regular UPI users, alongside the five-app teardown. UPI was the default for all of them and cash the exception, so the question was never whether people pay this way. It was what happens to the record afterwards.
They were describing a tracker, inside the app they already pay with.
What 70% asked for, unprompted
Third-party trackers ask for a payment that has already been made, a second time, by hand. A few people track deliberately; most start, stop, and fall back to a rough sense of the total.
Transaction lists are complete and unreadable. Nothing groups them, so nothing explains them - and every person I spoke to had opened one at some point and closed it none the wiser.
Categorised spending, a periodic summary, and a report they could keep. Around 70% named all three unprompted - and not one of them named a feature that does not already exist somewhere.
[ GPay - The bet / 03 ]
Everything after this section is downstream of one call. Both routes solve the tracking problem on paper. Only one of them survives the finding above.
The payment and the record happen in the same gesture, so the record never has to be re-entered - which is the exact point at which every other attempt failed.
The record is made where the payment already is
A dedicated surface with room to go much deeper - budgets, goals, multi-account reconciliation - answering to nobody else's interface.
Just improve the existing transaction history. Rejected because a history answers what happened and the question people are actually asking is what am I doing. Better sorting and filtering still leaves the reader to do the summarising - the work here is the grouping and the periodic reading, not the record.
[ GPay - The constraint / 04 ]
Measured,
not argued
A counter, a printed QR code, and a real payment on the clock. That window is the only real objection to this concept - does the addition disturb the payment? - and it is answerable rather than arguable. One tap on a sheet that is already open, before the PIN, spends none of the part that matters.
[ GPay - The feature / 05 ]
And nothing else added. Each one earns its place by removing a step someone is currently doing by hand.
Three sources decide a category: the merchant, the user's own history, and the tap on the sheet.
Nothing is inferred silently
Every payment lands in a category as it is made. The month arrives already grouped - food, travel, bills, people - with the total that follows from it.
Replaces the spreadsheet
The note field becomes a row of categories to tap, editable and reorderable, with free text still there for the payment that does not fit one.
Removes the typing
A short reading at an interval the user sets - what went where, against the same period last time. Enough to notice a pattern before the balance does it for you.
Catches it early
Any period exported as a readable report and sent through Gmail or WhatsApp - for a household, an accountant, or a claim.
Makes it usable elsewhere
Three sources, in order. The merchant, where the payee already resolves to a known type. The user's own history with that payee, once there is any. And the tap on the payment sheet, which both records this payment and teaches the first two. Nothing is inferred silently, and every category stays editable after the fact.
[ GPay - The structure / 06 ]
Four concepts under eleven names. That is not a naming problem; it is no architecture at all.
Why it was dropped
So I followed the one Google Pay already ships: three roots, everything under them.
It had "Money settings", "Manage Expense", "Detailed Insights", "Manage Downloads" - four ideas wearing eleven labels. A concept feature that re-teaches navigation breaks the app it is being added to.
The three
roots
Untouched, deliberately. Search, the four payment actions, the people you pay most. A feature about understanding money has no business slowing down the act of sending it, so the only thing it adds to this tab is a row of chips inside the payment sheet.
Everything the concept adds that is a reading. Balance, the month against its budget, the insight cards, the history and the reports. One tab to answer one question, rather than an insight surface hidden behind an overflow menu.
Everything the concept adds that is configuration, in one labelled group: budget, categories, alerts, reports and delivery. Reading and configuring are different jobs at different frequencies, and mixing them is what produced the eleven names.
How they
connect
Three flows, one per root, and the third hands back to the first. These are built in the page rather than exported, so they cannot drift from the screens they describe - every node below is one of the 23.
The fast path, and the one place the concept is a guest rather than the host. One chip row is added; the PIN step is not touched.
The reading, and the way out of the app. Ordered by how answerable each question is, most answerable first.
Configuration, visited rarely, so it can afford to be explicit. It ends by changing the one row Flow 01 depends on.
Before any
of it looked
finished
Low fidelity first, so the argument could be tested before the interface could flatter it.
[ GPay - The screens / 07 ]
Not a highlight reel. The happy path, the reading it produces, and the settings behind both - in the same order as the three flows above. The six states that decide whether any of it survives a real account are the section after this one.
The fast path, and the one place the concept is a guest rather than the host. One chip row is added to the payment sheet; the PIN step is not touched at all; and the receipt is where the reading is finally earned.
Left exactly as it is. Nothing here mentions budgets, because a feature about understanding money has to stay out of the way of sending it.
Left alone on purpose
One row of category chips under the amount, and the whole concept rests on it. Tapping one is the entire interaction - no form, no second screen, and skipping it costs nothing.
One tap, no form
Free text is still there for the payment that does not fit a category. Different data, not an alternative - and it never travels with the payment.
The exception, not the rule
Untouched. No extra field, no extra tap, no delay. The measured window says the addition has to sit before this step, and it does.
Not touched at all
Paid - and what it just did to the month: 83% of the budget, up from 82%. The reading is earned here, at the only moment the reader is already looking.
Where the reading is earned
One tab to answer one question. The reading, then the two ways of going deeper into it, then the way out of the app entirely - each screen ordered by how answerable the question it serves actually is.
One tab to answer one question. Balance, the month against its budget, two insight cards, then history - in that order, because that is the order the questions arrive in.
One tab, one question
The pace, and the projection - "at this pace you will finish near Rs 36,800". A number that has not happened yet is the only one that changes a decision.
A projection, not a total
Grouped by day, each header carrying that day’s total. A list that sums its own groups is the difference between a record and a reading.
Every header carries a total
Finds a payee, an amount or a note. The history was always complete; this is the first time it is answerable.
Complete, and now answerable
The button counts before it commits - "Show 42 results". Nobody should have to apply a filter to find out whether it was worth applying.
It counts before it commits
One card a month, each stating its real state: in progress, sent, or expired. A card that lies about its state is worse than no card.
Each states its real state
Configuration, visited rarely, so it can afford to be explicit. Every row carries its current value, which makes the list itself a summary - and the last of them changes the one row the payment sheet depends on.
Money settings as its own labelled block. Reading and configuring are different jobs at different frequencies, and mixing them is what produced the eleven names.
Configuration, kept apart
Four primary on the payment sheet, everything else one level down, and the user picks which four. This screen is why Flow 03 exists.
The user picks the four
A name, a colour, and one switch. Fifteen characters, counted on screen - a chip that wraps to two lines has stopped being a one-tap target.
Fifteen characters, counted
The threshold that fires the budget alert, and the only interrupt this concept is allowed. Opt-in, and set to a number the user chose.
The only interrupt allowed
Gmail verified, WhatsApp not set up - so nothing is scheduled to it. Each destination carries its own state rather than a single global switch.
Each carries its own state
[ GPay - The states / 08 ]
Six screens, and each one is a specific failure the happy path would have hit: a number too large for its container, a script too tall for its line, a bar asked to show 142% of itself, a month with nothing in it yet. These are the ones that decide whether this is a concept or a product.
Fires at the threshold set in Alerts, and names the biggest mover rather than just a percentage. "Not now" sits on the left because dismissing is the more common answer, and the common answer gets the easier target.
The only interrupt allowed
Rs 1.25 Cr. Summaries abbreviate above a lakh so the headline stays on one line; rows never do, because a row is a record and a record has to be exact. Indian grouping throughout.
Abbreviate summaries, never rows
142% of the budget. The bar stops at 100% and the overage is written beside it - a progress bar that can exceed its own track is one nobody can read a value off.
The bar stops at 100%
The amount column is fixed, so a long merchant name truncates instead of pushing a figure off its own edge. Tamil sits on a 22px line where Latin uses 20 - a clipped script is not a rendering bug, it is an exclusion.
A taller line for a taller script
Nothing to summarise yet, said plainly, with the one action that changes it. An empty state that explains what will fill it is the difference between reading as new and reading as broken.
Explains what will fill it
Same heights, same radii, same positions as the screen it becomes. Nothing shifts when the data lands, which is the only thing a skeleton is actually for.
Nothing shifts on arrival
[ GPay - What's next / 09 ]
This is a concept study, not a shipped feature. Three things I would want to know before anyone builds it, in the order they could sink it.
The whole promise is that filing is one tap or no taps. If merchant resolution is weak in practice, every payment needs a manual tap and the feature quietly becomes the thing it replaced. That is the assumption I would test first, and it is the one that could sink it.
A categorised profile of someone's spending is a different asset from a list of transactions, and this study does not say who holds it, where it is computed, or how it is turned off. On-device categorisation is the obvious answer and I have not costed it. This is the largest hole in the work.
Export and delivery - most build, least daily use, and the only one of the four that depends on external services. The reading is what people asked for; the report is what they said they would like.
[ GPay - The persona / 10 ]
Primary
persona
“I know roughly what I spend. I have no idea what I spend it on.”
Nithya, 26
Marketing executive, Bengaluru
