Payments built in, not bolted on

Payments that reconcile themselves.

M-Pesa isn't a side feature added to the till - it's built into how every sale is recorded.

The problem this solves

For most Kenyan businesses, M-Pesa isn't optional - it's often the majority of transactions. And yet in a lot of systems, it's treated as an afterthought: a separate payment method that has to be manually matched to a sale after the fact, by someone squinting at an M-Pesa message and a till receipt at the end of a long day, hoping the numbers line up.

How it works

STK push payments are tied directly to the specific sale that triggered them at the moment of the transaction - not reconciled afterward by a person cross-checking two separate records. Per-tenant Daraja credentials mean each business's M-Pesa integration is its own, secure and separate from every other business on the platform. When a customer pays, the system already knows which sale that payment belongs to.

Why we built it this way

We looked at how much of a typical Kenyan retail day's admin time goes into manually reconciling M-Pesa payments against sales - and decided that entire category of work should not exist. If the payment method is the dominant one in the country, it should not be the one the software treats as an exception.

What's included

Questions that usually come next.

Next step

Talk through the setup before you build around it.

The best setup depends on how your branches, payments, and stock actually work today.

Talk to us

Payments that reconcile themselves.

The problem this solves

How it works

Why we built it this way

Capabilities in the platform

STK push integration tied to the originating sale

Per-business Daraja credentials - no shared or pooled accounts

Automatic reconciliation, no manual matching required

Support for cash and M-Pesa within the same till, side by side

Questions that usually come next.

Talk through the setup before you build around it.