← All work

(Case study 01 / 07 — Mobile · Flutter)

Co-Branded Credit Card

End to end

From an empty Flutter plugin to a live card module

Role
Co-built with one teammate. I scaffolded the Flutter plugin and owned most of the card module after onboarding, from bank API integration to host-app release.
Status
Live in the app, including in-app bill payment.
Stack
  • Flutter
  • Dart
  • Kotlin
  • BLoC
  • GetX
  • Remote Config

(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.

Next case studyCredit Card Onboarding PWA

(Hiring? Let's talk)

Let's buildsomething that ships.