Design a mobile payments app like Google pay
PremiumMobile systemHard
- UPI
- Device binding
- Idempotency keys
Quick answer
This mobile system interview question asks you to design a mobile payments app like Google pay. Aim for a design that meets its requirements at the stated scale, then explain its main components, data flow and trade-offs. Interviewers want to see how you scope the problem, size it and defend each choice.
The problem
Design a mobile payments app like Google Pay for UPI in India, on Android and iOS. Users scan a QR code or pick a contact, enter their UPI PIN and pay from their bank account in seconds. The hard parts are binding the account to the phone and SIM, never paying twice on a bad network, and handling payments that stay pending.
The payment service provider backend and the UPI network are a given. Design the app.
What must a mobile payments app like Google pay do?
- Onboarding: Verify the phone number through the SIM, link a bank account and set or reuse a UPI PIN.
- Pay: Scan a QR code or pick a contact, see the payee's verified name, enter the amount and PIN, and get a clear result.
How well must it do it?
- Never pay twice: Retries, double taps, app kills and network drops never create a second payment.
- Device trust: Payments only from the bound device and SIM, with a hardware-backed key and integrity checks.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- UPI
- Device binding
- Idempotency keys
- Pending payment reconciliation
- Android keystore
- Play integrity API
How you’ll practise
- Requirements
- App architecture
- Data and offline sync
- Networking and push
- Performance, battery and releases
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any mobile system design round.
- Clarifies the requirements before drawing anything
- Uses a few numbers that actually change the design
- Draws a clear path from the client to storage
- Picks storage and caching with reasons, not by habit
- Explains what breaks first under load and how to fix it
- States trade-offs openly instead of claiming a perfect design
Questions people ask about this interview question
- Which design type is this question?
- It is a mobile system question. You design a mobile payments app like Google pay and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Hard. It suits engineers preparing for senior interviews, where you are expected to drive the discussion and go deep on trade-offs.
- What should I cover first?
- Start with the requirements: what the system must do, how well it must do it and which numbers change the design. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team