A shop assistant completing a sale on the sell.ke POS, with a barcode scanner and a receipt printer on the counter

    MTN Mobile Money

    Every MoMo payment against the sale that earned it

    In Uganda, Rwanda and Ghana, most of the money crossing a shop counter arrives from a phone, and most of that is MTN MoMo. The payment is instant, the confirmation is immediate, and then it goes somewhere your business records are not.

    At close, the shop has a MoMo statement that lists amounts and times, and a day's trading that lists goods — and reconciling the two is a manual comparison that nobody keeps up for long. The gap between them is where the money goes missing, and it is almost never dramatic. It is five thousand here, a redirected payment there, a refund nobody logged.

    sell.ke closes the gap by attaching the payment to the sale at the moment it happens, so the statement becomes something you check rather than something you reconstruct from.

    What you get

    What changes at the counter

    The reference sits on the sale

    The cashier records the MoMo transaction against the specific sale it paid for. Your statement line and your sale line now point at each other, so a day's MoMo total either matches or tells you exactly which sale it does not match on.

    The day splits itself

    MoMo, Airtel Money, cash, card and anything on account are totalled separately at close. You stop asking what came in and start asking whether what came in is in the right place.

    A redirected payment becomes visible

    A sale that is closed with no payment attached, or closed as cash while the goods left and the drawer did not grow, is a line in a report rather than a shortfall you notice next quarter.

    The money lands in your own account

    Payment goes to your own merchant code. sell.ke records that it happened; it never sits between your customer and your money.

    The fraud nobody puts in the brochure

    Ask any shop owner in Kampala or Kigali what their worst mobile money problem is and very few say the charges. They say the cashier who tells a customer to send the money to a different number.

    It works because the shop has no record tying a payment to a sale. The goods leave, the customer is satisfied — they paid, after all, and they got a confirmation SMS — and the owner finds out, if ever, by noticing that stock is short and takings are flat. By then it is weeks later, there is nothing to investigate, and the only available response is suspicion of everybody.

    The fix is not surveillance. It is that every sale has to be closed against a payment, and the payment has a reference and an amount recorded against it. A cashier who redirects a payment now has to close the sale as something — cash that is not in the drawer, a MoMo reference that is not on the statement, or an unpaid sale sitting in a report with their name on it. The behaviour stops being invisible, which is usually enough for it to stop.

    Reconciliation, and why it quietly stops happening

    Every shop reconciles mobile money for the first two weeks. Then a busy Saturday happens, the comparison is skipped, the next day starts from an unverified position, and within a month the exercise has become archaeology nobody has time for.

    What makes it unsustainable is the shape of the task: two lists that were never designed to be compared, one ordered by goods and one ordered by time, matched by a human reading amounts. It is slow, it is error-prone, and it produces no useful output when it succeeds — just the absence of a problem.

    Recording the payment on the sale inverts that. The matching is done at the counter, by the person who was standing there, in the two seconds after the confirmation arrives. At close, the question is no longer which lines correspond but whether the totals agree — and when they do not, the system can tell you which sale is responsible rather than leaving you to find it.

    • Payment method and reference recorded on the sale, not after it
    • Day-end totals per rail, per cashier, per branch
    • Unpaid and part-paid sales visible as a list rather than a shortfall
    • Refunds and voids behind a manager PIN, with a name against each one

    What MoMo markets have in common, and where they differ

    MTN MoMo behaves similarly enough across Uganda, Rwanda and Ghana that one way of working covers all three: a merchant code, a confirmation to the customer, a statement to the business, and a charge structure that makes the difference between a personal number and a merchant arrangement worth understanding.

    Where the markets diverge is on everything around the payment. Uganda runs MoMo and Airtel Money as genuine rivals, so a shop needs both and needs them separated at day-end. Rwanda is more MoMo-dominant and far more interested in what your records say about stock, because of how EBM cross-checks. Ghana's wallets interoperate, and a single QR can be paid from any of them — which simplifies the counter and changes nothing about your need to know which sale was paid.

    sell.ke handles the common part the same way everywhere and lets the country pages carry the rest: the rails, the regime and the currency each market actually runs on.

    What sell.ke does not do here

    sell.ke does not push a MoMo payment request to your customer's phone. Kenya's M-Pesa STK push, through Safaricom's Daraja API, is the one mobile-money push the platform ships today — in MoMo markets the customer pays your merchant code the way they do now, and the cashier records the payment against the sale.

    That is a smaller difference at the counter than it sounds, because the two seconds of recording is not where shops lose money. The loss is in the reconciliation that never happens and the payment that went to the wrong number — both of which this fixes. If a MoMo collections integration ships, this page will say so.

    Questions

    MTN MoMo at the till — questions

    Does sell.ke send a MoMo payment prompt to the customer?

    Not today. M-Pesa STK push in Kenya is the one mobile-money push the platform ships. In MoMo markets the customer pays to your own merchant code exactly as they do now, and the cashier attaches the payment to the sale — which is the step that makes the day reconcile and makes a redirected payment visible.

    Does the money pass through sell.ke?

    No, and it should not. Payment goes from your customer to your own merchant code and settles in your own account. sell.ke records that the payment happened and which sale it paid for. A POS vendor sitting between a shop and its takings is a risk to the shop, not a feature.

    How does this stop a cashier redirecting a payment to their own number?

    By making every sale close against a recorded payment. Goods cannot leave on a sale with nothing attached without that sale appearing in a report — unpaid, or marked as cash the drawer does not have. The cashier who redirects a payment has to leave a trace somewhere, and a trace is all an owner needs. Combine it with manager-PIN authorisation on voids and refunds and the easy version of this fraud disappears.

    Can I take MoMo and Airtel Money in the same shop?

    Yes, and you should — in Uganda especially, where the two rails rarely serve the same customers. Both are recorded against the sale and totalled separately at close, so you see what each rail actually brought in rather than a single mobile money figure that hides the split.

    Which MoMo markets does this work in?

    Anywhere MTN MoMo runs, because the mechanism is recording rather than integration. The markets sell.ke has pages for are Uganda, Rwanda and Ghana; the same approach works in any market where your customers pay a merchant code and you get a statement afterwards.

    What about the transaction charges?

    They are between you and MTN, and they differ between a personal number and a merchant arrangement — which is worth checking, because many small shops are still taking business payments on a personal wallet and paying for it twice over. sell.ke records the sale value; what you net after charges is a question your MoMo arrangement answers.

    Can I use it for more than one shop?

    Yes. Branches share one product catalogue but hold their own stock, so a transfer between them is a recorded movement rather than a re-count. Reports run per branch or across all of them, and staff permissions are set per branch — a Kisumu supervisor does not need to see Nairobi's margins.

    Do I need internet?

    Not to keep selling. Offline mode lets the till take sales, print receipts and reserve stock while the connection is down, then syncs everything when it returns. You do need connectivity for the parts that are inherently online: an M-Pesa STK push, an eTIMS submission and the online shop all need a live link.

    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.

    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.