Taking payments online in Kenya: what the options actually cost

Taking money online in Kenya means M-PESA first and cards second, and the difference between doing it well and doing it badly is mostly about what happens after the money arrives.

## Paybill or Till

A **Till** is for paying for something at the point of sale. The customer pays, you see the payment, and matching it to a sale is your problem.

A **Paybill** takes an account number with the payment, which is what lets you match the payment to an invoice, an order or a student automatically. If you invoice, or if payments need to be matched to anything, you want a Paybill.

The application is paperwork and takes time. Start it earlier than you think you need to.

## The reconciliation problem

This is the part that catches people out, and it is worth understanding before you choose anything.

Money arriving is easy. Knowing which order it was for is the hard part. Without an account number, you are matching a phone number and an amount against a list of orders by hand, and at any volume that becomes somebody's entire afternoon.

That is the whole argument for a Paybill and for connecting it properly. The alternative is a person scrolling through messages.

## Daraja, and what STK push is

Daraja is Safaricom's developer interface. What it buys you on a website is **STK push**: the customer enters their phone number, a prompt appears on their phone, they enter their PIN, and your system is told the payment succeeded, with the reference attached.

That last part is the point. The payment arrives already matched to the order. Nobody types anything.

The alternative, displaying a Paybill number and asking the customer to pay and then send you the code, works, and it loses a meaningful share of customers at that step, and it puts you back in the reconciliation problem.

## Cards

Worth having for corporate customers and anybody outside Kenya, and not worth building the site around. For most Kenyan consumer businesses, cards are a minority of transactions.

Use an established provider rather than integrating with a bank directly. Card details must never touch your own system; that is a compliance burden you do not want and do not need.

## Fees

Every method has them and they differ by amount and by provider. Get the current rates in writing from each provider before you decide, and work out the cost on your actual average transaction rather than on a headline percentage. The fixed component matters a great deal on small transactions and not at all on large ones.

## Refunds and reversals

Sooner or later you will need to give money back, and it is worth knowing how before the first angry customer asks. M-PESA payments can be reversed or refunded, but the process depends on how you were paid and on your arrangement with Safaricom. Card refunds go back through the provider that took the payment and take several days to reach the customer.

Whichever you use, record the refund against the original sale, so your records show one sale and one refund rather than two unrelated amounts that someone has to match up at the end of the month.

## What to insist on, whoever builds it

The amount charged must be calculated on the server from your own prices, never taken from the browser. A price sent by a web page can be changed by whoever is using it.

The payment confirmation must come from the provider directly, not from the customer's browser after the redirect. A redirect can be faked or simply lost when a phone drops the connection.

And the same confirmation arriving twice must not create two orders. It will arrive twice eventually.

If the person building your site cannot explain how they handle those three, that is the conversation to have before the work starts.