Platforms and marketplaces
Systems collecting from customers and paying out to sellers, riders or agents.
- Collections
- Payouts
FinTech · Payment Systems Engineering
Payment Platforms Payment systems engineered around the money, not around the demo.
CodeWave designs and builds payment-oriented systems — collections, wallets, checkout and payout flows — where M-Pesa, Stripe, PayPal and partner APIs are wrapped in transaction workflows with statuses, ledgers, reconciliation and reporting.
- Channels
- M-Pesa · Stripe · PayPal
- Flows
- Collections · wallets · payouts
- Built in
- Ledgers, statuses, reconciliation
- Technology
- ASP.NET Core · Laravel · Redis
Channels
M-Pesa
Stripe
PayPal
Partner API
Workflow
- Initiated
- STK Push sent
- Confirmed
- Settled to ledger Queued
callback · retry · reconcile
Ledger
CreditKES ———
DebitKES ———
CreditKES ———
FeeKES ———
ReconciledBalanced
01 · The problem
Payment integrations rarely fail on the happy path.
Almost anyone can make a payment succeed once in a demo. The cost lands in the cases that follow — and they all involve money.
A payment integration is a distributed system with an unreliable network in the middle and a customer who has already been debited. It has to be engineered for the day it goes wrong, because that day decides whether the business trusts its own numbers.
The callback that arrives twice
A provider retries a notification and the system records the payment again — unless it was built to recognise it.
The callback that never arrives
The customer has paid, the system never hears about it, and support becomes the reconciliation process.
Payments in an unknown state
A request times out and nobody can say whether the money moved without checking the provider by hand.
Money that cannot be matched
A payment lands with no reliable link to an order, invoice or account.
Statuses that mean different things
The system, the provider and the finance team each have their own definition of "paid".
Reconciliation as a monthly crisis
Because nothing was designed to be compared, comparing becomes a manual project.
02 · Who it is for
Businesses where the payment is the product's spine.
If money moving through your system is what the business depends on, the integration is not a feature at the end of the project.
Wallet and fintech operators
Businesses holding balances for their users and needing a ledger that balances.
- Ledger
- Statuses
Businesses collecting at scale
Retail, service and subscription businesses taking payment through several channels.
- M-Pesa
- Card
Existing systems adding payments
Teams with a working system that now needs payment handled properly inside it.
- Integration
- APIs
03 · How a payment moves
Every transaction, traceable from initiation to reconciliation.
The shape of a payment flow CodeWave builds. Each step is a recorded state, which is what makes the transaction answerable later.
-
01
Payment initiated
The system creates the transaction and records what it is for before any money moves.
System
-
02
Customer authorises
STK Push, checkout or a direct payment to the business Till or PayBill.
Customer
-
03
Provider responds
The provider confirms, declines or times out — and the response is treated as data, not truth.
Provider
-
04
Callback handled
Notifications are processed idempotently, so a repeat cannot create a second payment.
System
-
05
Transaction verified
State is confirmed against the provider rather than assumed from the first message received.
System
-
06
Recorded to ledger
The movement is written with its reference, so the balance has an explanation.
Ledger
-
07
Reconciled
What the system holds is compared with what the provider reports, on a defined cycle.
Finance
-
08
Reported
Settled, pending and failed transactions are reportable without exporting anything by hand.
Business
Transaction states the system distinguishes
Initiated
Pending
Authorised
Confirmed
Failed
Expired
Reversed
Settled
Reconciled
"Paid" is not one state. Separating them is what lets a business answer, at any moment, whether a specific customer's money actually arrived.
04 · Channels
The rails we integrate, and what each one demands.
Every provider has its own behaviour, its own failure modes and its own go-live process. Knowing them in advance is most of the work.
M-Pesa · STK Push
A payment prompt on the customer's phone. The engineering matters in the gaps: the prompt the customer ignores, the one they approve after the request expired, the confirmation that arrives twice.
M-Pesa · Till
Customer-initiated payment to a business Till, which arrives without knowing what it was for. Matching it to an order or account is the part worth designing.
M-Pesa · PayBill
Account-referenced payments where the reference is entered by a human — so validation and matching have to tolerate what people actually type.
Stripe
Card and international payments, with webhooks, disputes and refunds handled as part of the transaction lifecycle rather than out-of-band.
PayPal
International collection where the customer expects it, integrated with the same status model as every other channel.
Partner and bank APIs
Where a business has its own arrangements, those APIs are integrated with the same discipline — recorded state, retries and reconciliation.
05 · How we engineer it
The parts that only matter when something goes wrong.
Which is to say: the parts that matter. These are the design decisions that separate an integration that works from one you can run a business on.
Idempotent callbacks
A notification processed twice must not create two payments. Handling is keyed so repeats are recognised, not replayed.
Timeouts and unknown states
A request that times out leaves the transaction in a defined state with a way to resolve it — never in silence.
Explicit state transitions
Payments move between recorded states, so "what happened to this transaction" has an answer with timestamps.
Retries with backoff
Transient provider failures are retried deliberately rather than abandoned or hammered.
Provider references kept
Every transaction stores the provider's own reference, which is what makes reconciliation possible at all.
Ledger discipline
Movements are written as entries that balance, rather than as a number updated in place.
Secrets handled properly
Credentials live in the deployment environment, not in code, and not on this page.
Validation before value
Requests are validated before anything is initiated, because the cheapest failure is the one that never started.
Observability
Payment flows are logged and monitored so a problem is noticed by the team rather than reported by a customer.
06 · Ledger & reconciliation
A balance is only as good as its explanation.
Systems that move money need to answer two questions at any moment: what is the balance, and which movements produced it.
CodeWave builds ledgers as entries rather than as a total that gets edited — so a balance can always be walked back to the transactions behind it, and what the system believes can be compared against what the provider reports.
- Every movement is an entry with a reference and a reason.
- Balances are derived from entries, never adjusted in place.
- Provider references travel with the transaction for comparison.
- Differences are surfaced as exceptions to be worked, not buried.
Reconciliation · period ———
System vs providerMatched
Pending
Exceptions
TXN-••••••
Collection
REF-••••
Matched
KES ———
TXN-••••••
Collection
REF-••••
Matched
KES ———
TXN-••••••
Payout
REF-••••
Pending
KES ———
TXN-••••••
Collection
REF-••••
Exception
KES ———
TXN-••••••
Refund
REF-••••
Matched
KES ———
entries balance · references retained · exceptions worked
07 · What we build
Payment functionality, inside business systems.
These are the shapes this work usually takes. Most engagements are one of them, or a combination that grew out of one.
Collections
Taking payment from customers reliably, through the channels they actually use, with every payment matched to what it was for.
Wallets and balances
User balances backed by a ledger, with movements that can be explained and audited.
Payouts and disbursement
Paying out to sellers, agents or staff, with approval, status tracking and a record of what was sent.
Subscription billing
Recurring charges, renewals and failures handled as a lifecycle rather than as a monthly script.
Payment APIs & webhooks
APIs for your own clients or internal systems, and webhook handling that survives provider behaviour.
Reporting and audit
Transaction reporting that finance can use, built from the same records operations work with.
08 · Said plainly
What CodeWave is — and what it is not.
Payments attract vague claims. Here is the boundary, stated once and clearly.
What we are
- A software engineering company
- Builders of systems that initiate and record payments
- Integrators of M-Pesa, Stripe, PayPal and partner APIs
- Designers of ledgers, statuses and reconciliation
- Responsible for the software, and for supporting it
What we are not
- Not a payment processor or aggregator
- Not a bank or financial institution
- Not a holder of your funds or float
- Not the party to your provider agreements
- Not a substitute for your own compliance obligations
09 · Technology
Chosen for systems that cannot lose a transaction.
Queues, caching, relational integrity and API design matter more here than framework preference — and the choice follows what the business already runs.
ASP.NET Core
Laravel
Redis
SQL Server
MySQL
M-Pesa Daraja
Stripe
PayPal
REST APIs
Webhooks
Provider credentials, endpoints and environment configuration belong to the client's deployment and are never published or shared between projects.
Clients
- Business system / app
- Customer checkout
- Operations & finance views
Application
- Payment initiation
- Transaction state machine
- Callback & webhook handlers
- Ledger & balances
- Reconciliation workflow
Providers
- M-Pesa Daraja
- Stripe
- PayPal
- Partner & bank APIs
Infrastructure
- Queues & background jobs
- Redis
- Relational database
- Logging & monitoring
Architecture at a conceptual level
10 · Business benefits
What good payment engineering buys you.
No figures here either — but every item below is something a finance team can feel within a month.
Fewer payments in limbo
Transactions have a defined state and a resolution path instead of an unanswered question.
No double-counted money
Idempotent handling means a repeated callback cannot inflate what the business believes it received.
Answers about one customer
A specific payment can be traced end to end without opening a provider portal.
Reconciliation that closes
Comparing system and provider is a routine, not a monthly investigation.
Reporting finance accepts
Operations and finance read the same records rather than arguing about two exports.
Faster channel additions
Once the transaction model is right, a new provider is an integration rather than a rewrite.
11 · FAQ
Payment platform questions.
Including the ones about what we are not — those matter most in this category.
Prefer the engineering story? Read the Wallet & Payment Platforms case study.
Is CodeWave a payment processor?
No. CodeWave is a software engineering company. We design and build the systems that initiate payments, handle provider callbacks, record transactions, keep ledgers and reconcile — integrating with providers such as Safaricom's M-Pesa, Stripe and PayPal. The money itself moves through those providers and the institutions behind them, under your own agreements with them.
Which payment channels do you work with?
M-Pesa through the Daraja API — STK Push, Till and PayBill flows — alongside Stripe and PayPal for card and international payments, and partner APIs where a business has its own arrangements. Which of them belongs in your system is a design decision, not a checklist.
What makes a payment integration reliable rather than just working?
The difference shows up in the cases nobody demonstrates: the callback that arrives twice, the one that never arrives, the customer who pays after the request expired, the network timeout that leaves a payment in an unknown state. Reliable integrations are built around those cases — idempotent handling, recorded state transitions, retries and a reconciliation path — not around the successful case.
Do you build wallets and payout systems?
Yes. Wallets, collections and payout flows are work CodeWave has built, with ledgers, transaction workflows and reporting behind them. What is appropriate for a given business depends on the regulatory and commercial arrangements it already has — which is part of the scoping conversation, not an afterthought.
Can you add payments to a system we already run?
That is a common engagement. We work with the system you have, design how payment state should live inside it, and integrate the provider without rebuilding what already works.
Who holds the funds and the merchant accounts?
You do. The merchant accounts, Till or PayBill numbers, provider agreements and settlement arrangements are the client's. CodeWave builds the software that works with them and never takes custody of funds.
How is reconciliation handled?
By designing for it from the start: every transaction carries its state and its provider reference, so what the system believes can be compared with what the provider reports. The exact reconciliation workflow is shaped around how the business closes its day, week or month.
More from CodeWave
Explore more CodeWave products
Payment Verification & Business Operations
MVerify
Know when the payment arrives.
- M-Pesa transaction verification
- Till and PayBill transaction monitoring
- Staff Android application
Explore MVerify
Business Management
POS & ERP Systems
One system from the till to the back office.
- POS and sales
- Inventory
- Customers and suppliers
Explore POS & ERP Systems
Property Management
Rental Management Platform
Every property, unit, tenant and payment in one place.
- Properties, units and tenants
- Rent and invoicing
- M-Pesa payments
Explore Rental Management Platform
Start a project
Bring us the payment flow you are worried about.
The one with the callback nobody trusts, the reconciliation that takes three days, or the channel you have been putting off. That is the conversation we are useful in.