What Nobody Tells You About Building Web Products for African Users

Most web development tutorials assume a set of defaults that quietly break down the moment your users are in Nairobi or Johannesburg instead of London or San Francisco. I’ve spent a lot of time researching how students and everyday users in South Africa and Kenya interact with digital products — payment flows, student portals, university platforms — and the gap between “works fine in the demo” and “works for your actual African userbase” is bigger than most product teams expect.
Here’s what I wish more dev tutorials flagged upfront.
PayPal is not a universal payment layer
This one catches a lot of teams building products with African market reach. PayPal has significant limitations in both Kenya and South Africa that don’t exist in the US or EU:
• In Kenya, PayPal supports receiving payments but heavily restricts withdrawals to local bank accounts. The workaround most Kenyan users rely on is linking PayPal to M-Pesa via platforms like Equity Bank — but that’s a multi-step process that a meaningful chunk of your users won’t complete.
• In South Africa, PayPal receiving limits and currency conversion rules create friction that most checkout UX doesn’t account for.
If your product assumes PayPal works the same way it does in a US/EU checkout, you’re silently excluding or frustrating a large portion of your African userbase — not because they can’t pay, but because your payment layer doesn’t match how money actually moves in their context.
M-Pesa is the default payment rail in Kenya — not a niche option
This is the flip side of the PayPal problem. For Kenyan users, M-Pesa isn’t an alternative payment method — it’s the first and most natural way they move money. Offering it as a secondary option below a card checkout that most of your users don’t have is backwards UX.
If you’re building anything that accepts payments from Kenyan users, Safaricom’s Daraja API (specifically STK Push) should be your primary integration, not your stretch goal. The STK Push flow sends a payment prompt directly to the user’s phone — they enter their PIN, done. No card details, no PayPal account, no bank redirect. For mobile-first markets, this is about as frictionless as payments get.
The most common integration pitfall: callback URLs. Daraja’s STK Push is asynchronous — your server finds out the transaction result via a callback, not via the initial API response. If that callback fails silently (usually because the URL isn’t HTTPS, isn’t publicly reachable, or isn’t whitelisted in the Daraja portal), your order gets stuck in “pending” forever. That’s worth planning for before you hit production.
Your users are almost certainly on mobile — and on constrained data
South Africa and Kenya both have smartphone penetration well above what many people expect, but the data cost context is very different from Western markets. Mobile data in South Africa is expensive relative to income; in Kenya, it’s cheaper but still a real consideration for everyday users. This has a few practical implications:
JavaScript bundle size matters more than you think.
A 400KB JS bundle that loads in 1.5s on a US connection might take 6-8 seconds on a mid-range Android on a South African mobile network. Google’s Core Web Vitals are stricter about this than most dev teams realize, but more importantly, real users drop off well before any benchmark kicks in.
Images need to be treated as a cost, not just a UX element.
WebP, lazy loading, and explicit width/height attributes aren’t nice-to-haves for African-targeted products — they directly affect whether a user on a prepaid data plan decides to stay on your page.
Test on actual mid-range Android devices, not just Chrome DevTools throttling.
DevTools throttling simulates network speed but doesn’t simulate the CPU and memory constraints of a low-to-mid-range Android phone, which is a much more representative device for a South African or Kenyan user than an M1 MacBook with throttling turned on.
University portals are a special class of pain
This one is specific to edtech or any product that integrates with African university infrastructure. South African and Kenyan university student portals are often hosted on legacy systems with inconsistent uptime, especially during peak periods like registration and exam results. If your product depends on scraping or polling a university portal, build in aggressive retry logic and clear “we’re waiting for the portal to respond” states — users will understand this, because they deal with it themselves.
For Kenyan universities in particular, M-Pesa paybill integration is the primary fee payment mechanism rather than a bank portal or card system. If you’re building anything in the Kenyan edtech space that touches fee payment, M-Pesa paybill number lookup and verification should be in your integration scope.
The broader point
Building for African users isn’t harder — it’s just different in ways that matter. The main shift is treating mobile-first and M-Pesa-first as the defaults rather than the edge cases, and not assuming that PayPal or Stripe will land the same way on the continent as they do in the West.
I’ve written more about the PayPal ↔ M-Pesa landscape from a user perspective here. if it’s useful context.

Happy to go deeper on any of these in the comments — particularly the Daraja callback handling, since that trips up a lot of first-time integrations.