Designing GPay + Wallet for Everyday Financial Habits

Google Wallet arrived in India with passes, tickets, loyalty cards, and document integrations. Those are useful utilities, but they do not automatically create a reason to revisit the product every day. GPay, by contrast, already sits inside a frequent and well-understood payment behaviour.

I used that tension as the starting point for an independent concept: rather than asking people to adopt another standalone destination, could Wallet become the layer that helps GPay users organise what happens before, during, and after a transaction?

“The opportunity was not to replace UPI. It was to use familiar payments as the moment where a healthier financial habit could begin.”

The project began with desk research into UPI, low-value transactions, offline payment constraints, document storage, account aggregation, and digital-wallet patterns. I also reviewed the Google Wallet Android experience and compared its proposition with behaviours already supported by payment, commerce, cloud-storage, and loyalty applications.

I drafted an interview guide around wallet use, document management, travel, security, rewards, personal finance, and micro-transactions. The source material does not contain a completed participant study, so this case study treats those questions as a research plan rather than presenting them as validated findings.

A bank can see only the transactions that pass through its account. A payment application sees another slice, and cash remains outside both. The concept positioned Wallet as a place where a user could deliberately bring these fragments together, then direct money into small purpose-built pockets.

I separated pockets into two intentions. Savings pockets protect progress toward a goal. Budget pockets make a spending allowance visible and available at the moment of payment. The same model can support individual or shared goals without turning the wallet into a full accounting product.

The Wallet area organises savings pockets, tickets, identity documents, and tracked orders, then gives goals their own balance, progress, funding controls, and transaction history. A user can keep personal goals or contribute to a group pocket without mixing every purpose into the account balance.

Pockets can also become payment sources. The selection sheet keeps bank accounts and wallet pockets in the same payment decision, so a budget is not a report checked later; it is an available balance when the user is about to buy.

The round-up interaction appears after a successful payment, when the amount and recipient are already clear. A user can save the difference immediately, choose a destination pocket, or allow spare change to accumulate before moving it. A second exploration places the choice before payment for people who prefer to decide the amount themselves.

After payment, the same system can group repeated transactions into meaningful categories and turn those groups into budget pockets. This avoids asking users to categorise every line manually before the product can show anything useful.

A year-end reflection concept

I also explored a story-like annual review that turns transaction data into an approachable summary of opening balance, closing balance, and memorable spending categories. It was an expressive concept, not a validated feature direction.

The exploration began too broadly. Tickets, documents, loyalty, identity, AI assistance, and payment all fit the word “wallet,” but combining them does not automatically produce a coherent product. The sharper direction came from choosing one repeated behaviour and designing around its timeline.

Looking back, I would validate the pocket model with people who already use UPI Lite, recurring savings, and manual expense tracking; test whether round-ups feel motivating or intrusive; and work through consent, account custody, withdrawal, failure, and privacy states before treating the concept as viable financial functionality.