(Case study 01 / 07 — Mobile · Flutter)
Co-Branded Credit Card
End to end
From an empty Flutter plugin to a live card module
(01) The problem
A partner bank's co-branded credit card needed a native home inside the company's super-app, right after users finished onboarding in a React web flow.
(02) What I built
- The Flutter plugin itself: routes, a WebView screen hosting the React onboarding PWA over a JavaScript bridge, an example host app and CI.
- A homepage on live bank APIs: balance tile, card widget, quick actions, and its own empty, loading and error state for every section.
- Card controls (lock, usage toggles, limits) behind one buffered, MPIN-gated save, plus statements and searchable transaction history.
- Card activation rebuilt around PIN setup when the bank retired its activation API, and a smoother transaction list with rebuilds scoped per tab.
- In-app bill payment (BBPS): bill details, amount validation, and one result screen for success, partial, failed and pending.
(03) The hard part
A payment the app can't confirm must never read as failed, because a user who sees "failed" after a debit may pay again. Every unknown result falls back to "in process", and the result screen polls the payment status every 30 seconds, up to 15 times, before settling on pending. The bank's native SDK also crashed on concurrent calls, so homepage requests run one at a time and are cached for every sub-screen.
(04) Result
The card lives inside the super-app on real bank data, and in-app bill payment went live through a Remote Config flag, without shipping an app release.
(Hiring? Let's talk)