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.
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.
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
Account hub in light mode
Profile, account information, security, connected accounts, support, and about are already grouped into one account surface.
Dark mode and localized profile flow
The same account surface also carries theme and language changes, so the product already shows real adaptation beyond one default screen state.
Biometric return flow
The app already supports a clean unlock path, greeting the user and routing through biometric or local security recovery instead of dropping back into generic auth screens.
Extra sign-in method linking
Recovery and account protection already go beyond a single login. Google, Facebook, passkey, and email are presented as additional verification paths in the account flow.
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.
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 architecturePayments 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 updatesFX 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 setCurrent 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.
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.
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
POST /payments/add-money/session
Authorization: Bearer <idToken>
Idempotency-Key: add-money-001
{
"amountMinor": 5000,
"currency": "GBP"
}
{
"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.
Loading updates...
Track progress in one place.
Architecture, docs, provider testing, and release progress stay in one place.