Case study · FinTech / payments
Wallet / Payment Platforms
Wallets, collections and payouts with reliable transaction workflows.
- Category
- Payments
- Industry
- FinTech / payments
- Platforms
- Web platform · Payment APIs
- Technology
- ASP.NET Core · Redis · SQL Server · M-Pesa
01 · Project overview
What was built, and for whom.
CodeWave builds payment-oriented platforms — wallets, collection and payout systems — where each channel is wrapped in the same disciplined transaction workflow. The result is a system where money is never "somewhere in between": every movement has a state, a ledger entry and a reconciliation record.
- Built for
- Payment operators and businesses moving money across several channels
- Type
- Selected project
- Platforms
- Web platform, Payment APIs
- Focus
- payments web saas
02 · Business challenge
The problem, as the business experienced it.
Moving money through M-Pesa, cards and partner APIs left transactions in uncertain states — callbacks missed, retries handled manually, and reconciliation done by hand at month end.
Payment channels each behave differently: M-Pesa calls back, cards authorise then capture, partners time out. Without a single workflow and ledger, the business absorbed the difference by hand.
- Transactions stuck in unknown states after missed callbacks
- Manual retries and manual customer follow-up
- No single ledger across channels
- Month-end reconciliation against statements by hand
03 · Our approach
How we got from the problem to the system.
Payment platforms with explicit transaction workflows (initiated → pending → confirmed → settled), double-entry ledgers, automatic reconciliation and partner APIs — across M-Pesa STK Push, Stripe and PayPal.
-
01
Understand
We documented every path a transaction could take on each channel — including the failure paths that were costing the most time.
-
02
Architect
A state-machine transaction workflow, a double-entry ledger and an idempotent API layer that partners and internal systems share.
-
03
Build
Core ledger and workflow first, then channel adapters for M-Pesa STK Push, Stripe and PayPal.
-
04
Integrate
Callbacks, retries and reconciliation against provider statements automated end to end.
-
05
Deploy & support
Deployed with queues, workers and monitoring sized for transaction load, with ongoing support.
04 · Solution architecture
Layers of the system.
Clients at the top, the core application in the middle, integrations and data underneath. Green marks the integration layer where the system meets the outside world.
Clients
- Operations portal
- Partner APIs
- Customer-facing apps
Application
- Transaction workflow engine
- Wallets & ledgers
- Reconciliation
- Payouts
- Reporting & audit
Channels
- M-Pesa STK Push
- Stripe
- PayPal
- Bank & partner APIs
Data & infrastructure
- SQL Server
- Redis queues & workers
- Monitoring & alerting
05 · Key features
What the system does.
Transaction workflows
Explicit states from initiation to settlement, with retries built in.
Wallets & ledgers
Double-entry ledgers so balances always reconcile.
Automatic reconciliation
Provider statements matched to ledger entries without spreadsheets.
Multi-channel payments
M-Pesa STK Push, Stripe and PayPal behind one API.
Partner APIs & webhooks
Idempotent APIs for partners and internal systems.
Reporting & audit
Every movement traceable, exportable and auditable.
06 · Technology
The stack behind it.
Chosen for the job — mature, supportable and straightforward to host and staff for in Kenya.
- Backend
- ASP.NET Core REST APIs WebSockets
- Data
- SQL Server Redis
- Integrations
- M-Pesa Daraja STK Push Stripe PayPal
07 · Business impact
What changed for the business.
Outcomes are described qualitatively. Figures are published only when verified by the client and approved for release.
-
01
Every transaction traceable from initiation to settlement
-
02
Automated retries and reconciliation instead of manual follow-up
-
03
One ledger across M-Pesa, card and partner channels
-
04
Reporting and audit trails available on demand
08 · Screens
Interface illustration.
A representative illustration of the interface, not a live screenshot — no client data is shown.
Channels
Workflow
- Initiated
- STK Push sent
- Confirmed
- Settled to ledger Queued
Ledger
Similar problem?
Have a process that looks like this one?
Tell us how it runs today. We will tell you what a system built for your operation would involve.