Kotlin Android app
Compose screens, ViewModels, Room-backed local continuity, identity UI, add-money flows, and release gating all live in the Android client.
Architecture | March 2026
How PaySmart is wired today.
Kotlin client flows, Functions Gen2 routes, provider-specific payment handlers, identity verification, and server-owned payment state.
Architecture principles
- Client UI stays responsive, but final money movement state remains server-authoritative.
- Provider-specific payment behavior is separated by route and handler.
- Identity and payment journeys publish progress through docs, updates, and release notes.
- Only current payment provider work is shown: Stripe sandbox and Flutterwave testing.
System topology
Payment state, provider logic, and client sync are separated clearly across the app and backend.
Functions Gen2 API
Auth-guarded handlers create sessions, read provider state, process webhooks, and expose the current FX quote route ahead of the next Kotlin implementation slice.
Firestore and storage
Sessions, wallet writes, identity payload records, and provider status transitions remain server-owned so UI state does not invent completion states on the client.
Payment path today
This is the current route shape reflected in the repo, not an abstract “future platform” diagram.
Provider-specific routes
- POST /payments/add-money/session for Stripe sandbox session creation
- GET /payments/add-money/session/:sessionId for final status checks
- POST /payments/flutterwave/add-money/session for active provider testing
- GET /payments/flutterwave/funding-account to read current account state
- POST /payments/flutterwave/funding-account/provision to provision test accounts
App request
Authenticated user action from add-money or funding-account surfaces.
→
API handler
Provider-specific request validation, idempotency, and session creation.
Provider
Stripe sandbox or Flutterwave test request, depending on the route.
→
Webhook or status read
Backend becomes authoritative for final session state.
Wallet mirror
Server updates persisted balance data.
→
Client sync
Room and UI refresh against confirmed server state.
Identity and security path
Identity is one of the most mature areas in the current codebase and remains central to the delivery model.
Identity upload flow
- Session creation returns upload parameters and attestation context.
- Document bytes are encrypted on-device before payload handling.
- Commit flow binds uploads to server-side review state transitions.
- Provider handoff routes support start, resume, and callback state management.
Security posture in practice
- Cloud KMS-backed identity handling remains in the architecture.
- Webhook settlement and wallet writes use idempotent gates.
- App Check and session controls are called out in the public update trail.
- Delivery updates stay aligned with implemented routes and flows.
Read the supporting docs behind the architecture.
Architecture notes, backlog updates, and release history support the current implementation view.