The Payment Gap That's Costing Kenyan Businesses (It's Not M-Pesa)

Let's get the obvious out of the way: if you sell online in Kenya, you have M-Pesa. Everyone does. Any developer worth hiring builds it in without being asked — it's simply how the country pays.

So "add M-Pesa" isn't the insight. It's table stakes.

The gap I actually see is quieter, and it costs more: sites built for only one kind of customer — and quietly losing the other one.

The customers M-Pesa can't reach

M-Pesa is perfect for the Kenyan on the ground. But a lot of businesses here have a second audience they under-serve: people who can't easily pay with it.

Think about who that is: - Tourists. A visitor wants to book your service before they even land in Diani. They don't have M-Pesa. If your only checkout is a paybill number, that booking is gone. - International clients. If you sell digital products, consulting, or anything across borders, your buyer pays by card — or through Gumroad, PayPal, Stripe. M-Pesa-only shuts that door. - Diaspora and corporate. People paying from abroad, or businesses that need a card trail.

The businesses that grow past purely-local aren't the ones with M-Pesa — everyone has that. They're the ones that make it just as easy for a foreigner to pay by card as it is for a local to pay by phone, without either audience feeling like an afterthought.

Having M-Pesa vs. having a smooth M-Pesa flow

Present isn't the same as frictionless.

The clean version: the customer taps pay, gets an STK push, approves on their phone, and your site confirms the order instantly — no manual steps. The clunky version: they copy a paybill and an account number, switch apps, pay, screenshot the confirmation, send it on WhatsApp, and wait for someone to check it by hand.

Every extra step there is a place to lose the sale — and a job someone on your team is doing manually. Automating the flow with the M-Pesa Daraja API (STK push + instant callback) isn't "adding M-Pesa." It's removing friction from a method you already have. That's where a real conversion lift usually hides.

Mobile-first is about the thumb, not the network

Your site is used on a phone. Not because connections are slow — Kenyan mobile data is fast and stable — but because that's simply the screen your customer is holding.

A layout designed on a desktop and squeezed onto a phone fails in small, expensive ways: buttons too close to tap, forms that need pinch-zoom, a booking flow that takes eight taps. None of that is a bandwidth problem. It's a design problem, and it quietly costs you conversions.

Two things worth getting right: - Thumb-friendly by default. Big tap targets, short forms, the key action always in reach. WhatsApp and call, one tap away. - Fast, or you lose prospects — everywhere. This isn't a Kenya problem; it's universal. A site that drags loses people before they even see your offer, and Core Web Vitals (a global Google ranking signal) means it ranks worse on top of that. A fast, well-optimized site is non-negotiable in any market — that's just good engineering, not compensating for the network.

What this looks like done right

A lot of Chef Angela's customers in Diani are visitors — people booking a private chef before or during a trip. That audience isn't paying by M-Pesa from London. So her site had to work for both worlds: effortless for a local, effortless for a tourist. Mobile-first, one tap to WhatsApp or book, no clumsy payment dance.

That's the whole point. Not "does it take M-Pesa" — of course it does — but "does it serve every customer who wants to pay you."

A quick payment & mobile checklist

Run your site against this:

1. 1. Can a local pay by M-Pesa in the fewest taps possible — ideally an automated STK push?
2. 2. Can a foreigner or international client pay without M-Pesa — card or a global option?
3. 3. Is the confirmation instant and automatic, not a manual WhatsApp check?
4. 4. Is every key action reachable with a thumb, no pinch-zoom?
5. 5. Does the site load fast enough to keep Google — and the customer — happy?

Each "no" is a customer you're quietly turning away.

FAQ

Isn't M-Pesa enough on its own? For a purely local business, often yes. But the moment your market includes tourists, diaspora, or international buyers, M-Pesa-only leaves money on the table. Serving both audiences is what unlocks the next tier of customers.

Do I need the Daraja API, or is a paybill fine? A paybill works, but a manual paybill-and-screenshot flow adds friction and manual reconciliation. Automating with Daraja (STK push + instant confirmation) cuts drop-off and frees you from matching payments to orders by hand.

Does mobile-first still matter if Kenyan internet is fast? Yes — it's about the device, not the connection. Your customer is on a phone, so the layout, tap targets, and flow have to be built for a thumb. And fast sites rank better on Google regardless of country.

How do I accept card payments for foreign customers? Through an international processor (Stripe, PayPal, or a local gateway that supports cards) running alongside M-Pesa. The craft is presenting both options cleanly, so neither audience feels second-class.

Serve every customer who wants to pay you

Most Kenyan sites nail the local customer and quietly lose the rest. If you want yours built to convert both — locals on M-Pesa and visitors on card — here's how I work.

Not sure where you're leaking customers? A free SEO Audit is a good place to start. And if you haven't yet, read why standard SEO fails in the Kenyan market.