Airtel Money
Airtel Money in the same book as everything else
Almost no shop in East Africa is single-rail. Even a business that thinks of itself as an M-Pesa shop or a MoMo shop takes a meaningful share of its money on Airtel Money, because a customer pays from the wallet they have.
So the second rail becomes a second book. It gets its own statement, its own float, often its own phone behind the counter, and it is reconciled less carefully than the first one precisely because it is smaller. Smaller and less watched is the combination that loses money.
sell.ke treats every rail the same way: the payment is recorded against the sale, and the day splits by method at close. The second rail stops being the one you check last.
What you get
What you get back
A real split at day-end
Airtel, MoMo or M-Pesa, cash, card and credit, each totalled on their own. You can finally see what share the second rail is carrying instead of guessing it.
Payments tied to sales
A reference recorded against the specific sale, so the statement is something you verify against rather than something you reconstruct the day from.
Per-cashier, per-branch visibility
If one counter's Airtel takings behave differently to every other counter's, that shows up as a number rather than as a feeling.
The same treatment online
A web order paid on a wallet and a counter sale paid on the same wallet land in the same report, tagged by channel.
Why the second rail leaks
A shop's attention follows its volume. The main wallet gets a dedicated phone, a known float and a nightly check. The second one gets whatever is left — frequently a personal handset, sometimes a staff member's own number, usually no routine at all.
That is how a rail carrying a quarter of a business's takings ends up with no reliable daily record. Nobody decided it; it happened by neglect, and neglect is a slow, consistent cost rather than a dramatic one.
The asymmetry also makes fraud easier to hide. A payment redirected on the main rail might be noticed. The same payment on Airtel, in a shop that only truly reconciles M-Pesa, is close to invisible — and people learn where the gaps are.
Interoperability changed the counter, not the books
Wallet-to-wallet transfers across networks now work in most East African markets, and in Tanzania instant interoperability routes a large volume of payments between providers. That removed a real friction: a customer on one network can pay a merchant on another without going through an agent.
It did nothing for your records. The payment still lands on whichever rail it lands on, still produces its own statement, and still has to be tied to the goods that left your shop. A customer paying across networks may actually make the problem harder, because the rail a payment arrives on is no longer predictable from the customer's network.
Recording the payment on the sale is what makes that irrelevant. Whatever arrives, wherever it arrives from, the sale it paid for is known at the moment it happens.
- Every rail treated identically — no main wallet and afterthought wallet
- Method and reference on the sale, totalled per rail at close
- Per-cashier and per-branch breakdowns
- Unpaid and part-paid sales as a list you can act on
Where Airtel Money runs, and what else is on the counter
Airtel Money is a serious second rail in Uganda and Tanzania, a genuine third option in Kenya alongside M-Pesa, and a meaningful share of Rwandan retail behind MoMo. It runs well beyond East Africa too, in Zambia, Malawi and the DRC.
In each of those markets it shares a counter with something else — MTN MoMo in Uganda and Rwanda, M-Pesa and Mixx by Yas in Tanzania, M-Pesa in Kenya. A shop does not get to pick; it takes what the customer offers and lives with the reconciliation afterwards.
The only sane way to run that counter is to stop treating rails as separate processes. One sale, one record, a payment method recorded on it, and a day that splits itself at close. What the customer chose becomes a reporting dimension rather than an operational problem.
What sell.ke does not do here
sell.ke does not push an Airtel Money payment request to your customer's phone, and the money never passes through sell.ke. Kenya's M-Pesa STK push via Daraja is the one mobile-money push the platform ships; everywhere else the customer pays your own merchant code and the cashier records it against the sale.
The value here is in the record and the reconciliation, not in the pipe. If an Airtel collections integration ships, this page will say so rather than being quietly reworded.
Questions
Airtel Money at the till — questions
Can I take Airtel Money and another wallet in the same shop?
Yes, and nearly every shop should. Both are recorded against the sale and totalled separately at close, so you see what each rail actually brought in — including the one you are not watching, which is usually the one worth watching.
Does sell.ke send an Airtel payment prompt?
Not today. The customer pays your own merchant code as they do now, and the cashier attaches the payment to the sale. M-Pesa STK push in Kenya is the only mobile-money push the platform currently ships.
Does interoperability between wallets change anything?
At the counter, yes — customers can pay you across networks without an agent. In your records, no: the payment still arrives on one rail, still produces its own statement and still has to be tied to the goods that left. Recording the method on the sale is what makes the routing somebody else's problem.
Can I see which cashier takes payments on which rail?
Yes. Takings break down by payment method, by cashier and by branch. A counter whose rail mix looks nothing like every other counter's is worth a conversation, and the point of the report is that you get to have it early rather than after a stock count.
What about online orders paid by wallet?
They land in the same report as counter sales, tagged by channel. One stock pool, one set of takings, with the channel as a dimension rather than a separate system — which is the whole argument for running the shop and the web store on one platform.
Does it work with M-Pesa?
Yes, at both ends of the business. At the counter a cashier sends an STK push and the customer approves it on their phone; the sale will not close until the confirmation lands. Merchants without Daraja API access can take a paybill or till payment and confirm the reference manually. On the online shop, M-Pesa is a checkout option like any other. The shortcode is the merchant's own, so the money lands in the business's account without sell.ke sitting in between.
Can I sell online with the same system?
That is the point of it. The storefront reads the same products, the same branch stock and the same price lists as the till — there is no sync job and no separate ecommerce subscription. A web order and a counter sale move the same stock and land in the same report, tagged by channel so you can see which one is actually growing.
Can I stop staff from giving discounts or deleting sales?
Yes. Discounts, voids and refunds sit behind a manager PIN, and every one of them records who authorised it and when. Staff accounts carry role permissions, so a cashier can sell without seeing cost prices, editing products or opening reports. A void that reverses stock is a movement in the audit trail, not a gap in it.
What does it cost?
Plans run from USD 12/month for a single-location till to USD 115/month for unlimited scale, with the online store on your own domain included from USD 23/month. In Kenya the same plans are KES 1,499 to KES 14,999/month, billed in shillings. Every plan starts with a 14-day trial and no card, and there is no per-terminal licence and no commission on your sales. There is no hardware to buy either — sell.ke runs on a phone, tablet or laptop you already own.
Go deeper on a feature
Each one goes further than this page does.
Selling at the counter
Split payments, held orders, manager-gated discounts and a drawer count that reconciles.
Reports and real accounting
Double-entry books — trial balance, P&L, balance sheet — not a CSV export to somebody else's software.
Branches, staff and control
Shared catalogue, separate stock, transfers that are movements, and permissions per branch.
Customers and loyalty
Credit accounts that do not go missing, loyalty that returns, and a debtor list you can actually chase.
The problems behind this
What this actually fixes in a working shop, written from the problem rather than from the regulation.
The drawer never balances
Cash, M-Pesa, MoMo and a notebook, reconciled by eye at 9pm. Here is the fix.
Not knowing your profit
Takings are not profit. The gap between them is where most small shops quietly fail.
Stock going missing
Why shrinkage is almost never one big theft, and what actually closes the gap.
MTN MoMo at the till
Every MoMo payment attached to the sale that earned it, instead of a statement you read at night.
EFD and VFD receipts (Tanzania)
Stop the fiscal receipt and the shop's own record from describing two different days.
EFRIS and your POS (Uganda)
Every sale held at the line detail a URA e-invoice needs, before you go to file it.
Try it on your own products
Fourteen days, no card, no hardware to buy. Import your product list or let Amina build it from a photo of your price list, and run it alongside whatever you use now.