The problem
Most engineers never work anywhere the cost of a bug is money that belongs to someone else.
A mobile wallet is not a normal app. It moves real funds between real people, under rules set by a regulator, and every one of those movements has to be reconstructable afterwards. You cannot ship a feature and watch what happens. You cannot quietly fix a bad state in production. And the interesting failures are not crashes. They are the cases where the app said one thing and the ledger recorded another.
I spent a year working inside that. It is the single most useful year I have had as an engineer, and it is why I am comfortable being trusted with the parts of a product where being nearly right is not a passing grade.
What I built
I worked on customer-facing wallet features in the mobile app: the flows people use to move money, and the screens that tell them what happened afterwards.
Payment flows, end to end. Not the happy path. The whole path. What the screen shows while a transfer is pending. What it shows when the network drops halfway. What it shows the second time you open the app, when the transaction has resolved and the answer has changed.
Failure states as designed screens, not error dialogs. In a normal app a failed request is a red toast. In a payments app it is the most important screen in the flow, because the user’s next question is where is my money and the answer has to be unambiguous. A large share of the work was there.
Release discipline. Every change went through review, staged rollout and a change record. Nothing shipped because someone was confident.
I am keeping the descriptions at this level on purpose. The specifics of how a regulated payments product is built internally are the employer’s, not mine to publish.
The hard part
Idempotency, and what it means for the person holding the phone.
The technical version is well-known: an operation should be safe to retry, so a duplicated request does not become a duplicated payment. Every payments engineer learns it early.
The version that took me longer was the interface one. A user whose screen freezes mid-transfer does not know whether the money moved. So they press the button again. Whatever the backend guarantees, the app has to make the second press feel safe and honest at the same time: it cannot silently swallow the tap, and it cannot suggest a second payment is being made when it is not.
Getting that right is not a backend concern that happens to have a UI. It is a product decision, made in the app, about what a person is told during the few seconds they care most.
The result
I am not going to put the employer’s numbers on my portfolio. Their transaction volume, their user base and their growth are theirs. I shipped features on the platform; I did not drive its scale, and claiming otherwise is the kind of borrowed credit that falls apart in one follow-up question.
What the year is worth to you is this. I have shipped software where mistakes cost money and get audited. I write for the failure case first, I assume the network will drop and I do not consider a flow done until I can say exactly what the user sees when it goes wrong. Clients get the benefit of that habit whether or not their project handles payments.
What I’d do differently
I treated the regulatory and compliance side as somebody else’s job for far too long.
It looked like process: reviews to satisfy, forms to fill, a delay between finishing something and it reaching anyone. So I optimised for getting through it rather than understanding it, and I lost time reworking things that a conversation upfront would have shaped correctly the first time.
The constraints were not obstacles around the product. They were the product. I would go and understand them properly in month one now, and I do exactly that on client work when a project touches payments, health data or anything under GDPR.