A deposit is the moment an enquiry becomes a booking. It is also, in a lot of operations, the moment the paperwork falls apart: money arrives on a phone, the confirmation sits in one person’s SMS, and three weeks later nobody can say with certainty which trip it was for.
This guide covers collecting safari deposits by M-Pesa in a way that reconciles — which product to use, what the limits actually are, and what to record.
Paybill or Till — which should you use?
Use a Paybill. The difference is one field, and that field is the whole reason this matters.
A Paybill is an organisation code. When a client pays, they enter your Paybill number, an account number, and the amount. That account number is arbitrary text you control — which means it can be your booking reference. Payments arrive already labelled with which booking they belong to.
A Till (Buy Goods) is designed for face-to-face point of sale — the short, anonymous transaction of a shop or restaurant. There is no account number. Payments arrive as a stream you reconcile by matching daily totals against sales.
For a supermarket, a Till is right. For a tour operator taking a deposit on a trip that will be delivered in four months, against an invoice, possibly in instalments, from a client who may also be paying for someone else — a Till throws away the only piece of information that makes the payment self-identifying. Both can be requested through the M-Pesa Business Hub.
What are the limits, and why do they matter?
They matter because a full safari deposit can exceed them, and finding that out while a client is standing at a payment screen is a bad time to learn it.
The standard limits, raised with Central Bank of Kenya approval in 2023:
- KES 250,000 maximum per single transaction
- KES 500,000 maximum total value per day
- KES 500,000 maximum wallet balance
Two practical consequences follow.
A deposit above KES 250,000 cannot arrive in one payment. It has to be split across transactions — and if the total also crosses KES 500,000, across days. That is workable, but only if you have told the client in advance. Otherwise the first failed attempt reads to them as something being wrong with your business.
The wallet cap constrains the client, not just the transfer. A traveller who does not routinely hold large balances may need to move money into M-Pesa before they can pay you at all, which takes time you didn’t budget for in your “confirm by Friday” deadline.
Where the deposit is large or the client is overseas, plan a second rail from the start rather than discovering the need mid-transaction.
How should you reconcile payments to bookings?
Three steps, and the first one has to happen before the client pays.
1. Give every booking a short, unambiguous reference. Short enough to type on a phone keypad without error. Avoid characters that are ambiguous when read aloud over a phone line.
2. Tell the client exactly what to enter. Not “use your name as the reference” — names arrive spelled six ways, and a family of four may pay under any of four names. Give them the literal string: “Paybill 123456, account number SS4417, amount KES X.” Put it on the invoice and in the message.
3. Record the M-Pesa confirmation code against the booking. Every completed transaction produces a unique confirmation code. Store it with the booking. It is the identifier both sides can quote if there is ever a question, and it survives the SMS being deleted.
The failure mode this prevents is specific and common: a payment that arrives correctly but is attributed to the wrong trip, discovered weeks later when a client who has paid is chased for payment. That single event costs more goodwill than the entire process costs to run.
What about currency?
M-Pesa settles in Kenyan shillings. That makes it excellent for clients who hold Kenyan mobile money and irrelevant for those who don’t.
Kenya’s inbound market is substantially international — the Tourism Research Institute recorded 2.7 million international arrivals in 2025, with Africa contributing 47%, Europe 25% and the Americas 14%. A large share of those travellers will never have an M-Pesa wallet.
The conclusion is not that M-Pesa is the wrong choice. It is that it is one rail among several, and the operational question is whether your records treat them consistently. A deposit is a deposit whether it arrived by mobile money, card or bank transfer; if each method lands in a different place and gets reconciled differently, the booking record depends on which rail the client happened to pick.
What should you decide before you take the first deposit?
Four policies, written down, applied to everyone:
- How much is the deposit, and when is the balance due? This guide deliberately won’t suggest a percentage — it depends on your supplier payment terms, your cancellation exposure and your cash position, and copying someone else’s number is how operators end up financing other people’s trips.
- What does the deposit secure, and for how long? A deposit against an unheld booking is a promise you may not be able to keep.
- What happens on cancellation? Decide before you need it, and put it on the quote.
- Who confirms receipt, and how fast? A client who has just sent a significant sum to a Paybill number wants confirmation quickly. An automated or same-hour acknowledgement is worth more than it costs.
The record is the point
Collecting the money is the easy part. M-Pesa does that reliably and has done for years.
What decides whether this scales is whether the payment, the booking, the invoice and the client record are the same record or four different ones. When they are separate, every payment needs a human to connect it to a trip — and that human is doing it from memory, at speed, while a client waits.
See how payments and finance works in Savanna Sync, or read our guide on pricing a safari package to get the deposit figure right in the first place.