TL;DR: A UPI wallet for 8 to 16 year olds. A parent funds and controls the account; the child gets real spending independence inside those limits. Payments were the easy part. The hard part was designing trust for two users who want opposite things: the parent wants control, the child wants to feel trusted.

Fintech case study · Product designer and PM (take-home product exercise) · Concept with clickable prototype

Figma prototype

The problem

Kids aged 8 to 16 increasingly need to pay for small things on their own (a snack, a school supply, a bus ticket), but UPI apps are built for adults with their own bank accounts and KYC. Parents end up either handing over their own phone and PIN or giving cash they can't track.

The brief was to design a secure, easy payment app for this age group, managed by parents. That meant solving four things at once: keeping money safe, handling more than one adult per child, making top-ups quick, and giving parents a clear record of what was spent.

Evidence

This was a timed product exercise, so there was no field research behind it. The design leans on how UPI apps already work in India and on one practical observation from the brief: not every parent will install a new app, so the money-request path had to work for them too.

How it works

Two interfaces sit on one payments backend. The parent account works like a standard UPI account. The child account is a separate wallet linked to it, opened with a 4-digit access code the parent sets.

Accounts follow a tree structure. A child can be linked to several parents or relatives who contribute money, but exactly one primary parent has the final say: they create the wallet, set limits, grant other adults access, block merchants and reset the access code.

flowchart LR
	P["Primary parent<br>(app or web)"] -->|"Creates wallet,<br>sets access code"| W["Child wallet"]
	P -->|"Sets allowance<br>= spending limit"| W
	C2["Other linked parents"] -->|"Contribute funds"| W
	K["Child app"] -->|"Pays by QR or<br>mobile number"| M["Merchant / contact"]
	W --> K
	K -->|"Requests more funds<br>(in-app or SMS)"| R{"Approve?"}
	R -->|"Yes"| W
	R -->|"No"| K
	K -->|"Every payment"| A["Alerts and<br>transaction history"]
	A --> P

Allowance and spending limits. Whatever the parent allots shows up in the child's app as a spending limit, alongside current balance and total funds allotted. The child can scan a QR code or pay a mobile contact, but only up to that limit. Spending is tagged by category (food, shopping, fitness and so on) so both sides can see where it went.

Allowance requests. When the limit runs out, the child can request more at any time:

1. The child picks which linked parent (or several) to ask, from the Request More Funds screen. They can also ask for a new adult to be added.
2. Any authorised parent can approve, from the app's Allot More Funds screen, which shows the last allocation and recent requests side by side.
3. Approved money lands in the wallet and the limit rises; the child sees which parent the funds came from in their payment history.
4. SMS fallback. The child can send the request as a text message. It carries a link to a web page where a parent who doesn't use the app can add funds directly. Parents can also create child wallets from the web, so the app is mandatory only for the child.

Tracking. Both sides get alerts and a monthly transaction history. After any payment, either side can open the details, recategorise it and notify the other.

Decisions and trade-offs