Project Status | March 5, 2026

Building PaySmart in public, one payment slice at a time.

PaySmart is in active development, with current work focused on Stripe sandbox payments, Flutterwave provider testing, identity verification, and the next FX implementation slice in the Kotlin app and Functions Gen2 backend.

Stripe sandbox active for add-money Flutterwave testing add-money and funding accounts Identity flow shipped FX quotes next slice
Current build surface Kotlin Android client, Firebase-backed auth, Functions Gen2 API, Firestore-backed payment state.
Provider testing now Stripe sandbox add-money, Flutterwave add-money sessions, webhooks, and funding-account work.
How progress is shown Implementation backlog, release notes, and the public update feed move with the codebase.
Kotlin Android client Functions Gen2 API surface Firestore payment and session state Cloud KMS identity payload security Stripe sandbox add-money flow Flutterwave provider testing lane

App screens from the current build

Product progress is easier to trust when real UI surfaces are visible. The account and security area is already one of the most complete parts of the app.

See build updates
Current UI

Security and privacy surface

Reset password, Transaction PIN, passkey status, biometric controls, privacy settings, and balance visibility are already grouped into one account-management flow in the Android build.

  • Passkey state is visible inside the profile security path
  • Biometric controls sit beside password and PIN actions
  • Privacy and balance visibility live in the same account surface
PaySmart security and privacy screen showing reset password, transaction PIN, passkey, biometric controls, privacy settings, and hide balance.

What is shipped, what is in test, and what is next

This summary follows the implementation backlog and recent release work across payments, identity, and FX.

Backlog last updated: March 5, 2026
Shipped

Identity verification flow

Upload-session, encrypted payload, attestation commit, provider session handoff, and review-state transitions are already reflected in the app and backend docs.

See the identity architecture
In Testing

Payments with real provider boundaries

Stripe add-money is stable in sandbox. Flutterwave routes are under active testing for add-money sessions, status reads, webhooks, and funding-account provisioning in supported regions.

View payment updates
Next

FX quote vertical slice

The FX route exists on the backend, but the Kotlin repository, cache, and UI wiring are still part of the next planned implementation slice.

Review the doc set
API-010 Create Stripe sandbox add-money session endpoint.
API-012 Webhook settlement and idempotent wallet write-through.
REL-003 Release notes aligned to current tester build and provider work.
APP-020 Live FX quote wiring planned for the next Kotlin slice.

Current focus

Current delivery work is concentrated on payments, identity, app state, and the supporting public update trail.

Active workstreams

  • Identity verification and provider session handoff
  • Stripe sandbox add-money session creation and webhook settlement
  • Flutterwave add-money session and funding-account testing
  • Kotlin client + Room-backed sync path for payment state
  • Public implementation backlog, release notes, and update feed

Delivery signals

  • Implementation backlog is updated alongside shipped slices
  • Release notes call out current tester build changes
  • Provider coverage shown here matches Stripe and Flutterwave work in the repo
  • Identity and security progress remain visible in docs and updates
  • FX is tracked as the next implementation slice

Architecture and state ownership

Payment routes, provider boundaries, and state ownership stay aligned with the current delivery model.

Open architecture details

Primary payment path

  • Android app requests a provider-specific add-money session.
  • Functions API validates auth, payload shape, and idempotency.
  • Provider-specific handlers talk to Stripe or Flutterwave.
  • Webhook or status polling becomes the source of truth for final state.
  • Wallet data mirrors back into user state and local client storage.
Kotlin app Add-money screens, identity flows, local persistence, and tester UI.
Functions API Route auth, create sessions, read statuses, enforce provider-specific contracts.
Stripe sandbox Add-money checkout session and webhook settlement path.
Flutterwave test lane Add-money session, webhook handling, and funding-account provisioning endpoints.
Firestore + wallet records Sessions, balances, and wallet transactions remain server-owned.
Room mirror + UI sync Client reads final state after backend confirmation.

For developers, reviewers, and early testers

Route names, delivery notes, and technical references stay visible for engineers, reviewers, and testers.

API surfaces visible in the repo now

  • POST /payments/add-money/session for Stripe sandbox session creation
  • GET /payments/add-money/session/:sessionId for final status reads
  • POST /payments/flutterwave/add-money/session for provider testing
  • GET /payments/flutterwave/funding-account and provision routes
  • GET /api/quotes already exists ahead of the Kotlin FX slice
  • /auth/identity/provider/* routes support provider handoff flows
Stripe sandbox request
POST /payments/add-money/session
Authorization: Bearer <idToken>
Idempotency-Key: add-money-001

{
  "amountMinor": 5000,
  "currency": "GBP"
}
Representative response
{
  "sessionId": "sess_01J...",
  "status": "pending",
  "currency": "GBP",
  "provider": "stripe",
  "checkoutUrl": "https://checkout.stripe.com/...",
  "expiresAtMs": 1772709600000
}

Recent development updates

Recent updates track provider testing, security work, release slices, and the next implementation steps.

Open the full update stream

Loading updates...

Track progress in one place.

Architecture, docs, provider testing, and release progress stay in one place.