Case study: building Sapthan Pay
Sapthan Pay is our own product: one app for every bank account a person holds across Europe. Here is what we built, and the engineering decisions behind it.
The problem
Many people in Europe bank in more than one country. Seeing their money means opening several banking apps, and paying a bill means remembering which account it comes from. Sapthan Pay puts every account in one place and lets people pay from any of them, while the bank stays in control of the money.
See the product at sapthanpay.com.
What we built
- Bank connections across Europe through Salt Edge, a provider regulated in the EU for account information and payment initiation. Users log in on their own bank's page; the app never sees their banking password.
- SEPA payments from any linked account, each approved with the bank's own strong customer authentication, with server-enforced limits of €500 per payment and €2,000 per day.
- Scan & pay for the EPC QR code (GiroCode) printed on European invoices: payee, IBAN, amount and reference fill themselves in.
- Insights and alerts: spending by category, a monthly budget, a day's notice before automatic debits, low-balance warnings against a floor the user sets, and a flag on payments worth a second look, such as a double charge or a subscription that went up.
- Statements for any period, downloadable as PDF or CSV.
The stack
- Native Android in Kotlin, chosen for direct access to the platform's security features.
- Firebase: Authentication (email and password, and Google sign-in), Firestore, Cloud Functions for every money-touching operation, Cloud Messaging for alerts, Crashlytics and Remote Config.
- Salt Edge open-banking APIs for account data and payment initiation.
Security decisions
A finance app is judged on what happens when something goes wrong, so security was designed in from the first screen:
- No bank credentials, ever. Bank login happens in the phone's browser on the bank's own page, not inside the app.
- Device integrity checks with Google Play Integrity and Firebase App Check before any payment request is accepted.
- One active phone per account. Signing in on a new phone signs the old one out, so a stolen password alone is not enough.
- Encrypted on the device with the phone's hardware-backed keystore, screenshots and screen recording blocked, balances hidden from the recent-apps preview, and an app lock using the phone's fingerprint, face or PIN.
- Limits live on the server, so they cannot be changed from a phone.
- Payments survive crashes. If the app closes mid-payment, it checks the true status with the bank on the next launch instead of guessing.
Privacy by design
App analytics record which screens and features are used, never amounts, balances or account numbers. Short-lived security records are deleted automatically by a scheduled job, and users can delete their account from inside the app.
Where it stands
Sapthan Pay is in pre-release testing with sandbox banks, ahead of its European launch.
What this means for your project
The same team builds client apps: native Android, Firebase backends, payment and banking integrations, and AI features. If your app handles money, personal data or anything else people need to trust, we have done it for our own product first.