Getting paid in Africa without excluding half your customers
MTN MoMo, Orange Money, Wave, Airtel, M-Pesa on one side; Visa and Mastercard on the other. What you learn wiring up a payment flow for a market where the bank card is the minority option.
The bank card is not the default payment method
That is the unspoken assumption behind most payment integrations: you plug in a European or American provider, you show Visa and Mastercard, and you consider the matter closed. The moment part of your audience is in Cameroon, Senegal or Côte d'Ivoire, that amounts to building a checkout those buyers cannot finish.
Payment goes through the phone. This is not an implementation detail to handle at the end of the project: it is a product decision that determines the conversion rate of everything upstream of it.
Two aggregators rather than one
On a recent project the audience was French-speaking in the broad sense: Europe, West and Central Africa, North America. These audiences do not pay the same way, and a single provider would inevitably have shut some of them out. The answer was to assemble two complementary building blocks: a multi-country Mobile Money specialist on one side, an international card provider on the other.
The market offers several options for each block. On the Mobile Money side, solutions like PawaPay, Flutterwave or CinetPay cover the operators of a number of African countries; on the international card side, providers like Dodo Payments, Stripe or Lemon Squeezy also handle tax and currencies. The right combination depends on your geography, not on a universal recommendation.
On Résidence Kesla the audience is local: NotchPay was enough, with coverage of the Cameroonian operators. You pick the aggregator on where your buyers actually are, not on how well known the provider is.
Payment status is a feature, not a log line
This is the main difference from card payments. A Mobile Money transaction can sit pending, expire without notice, or fail on the operator's side without your application ever being told properly. If your back-office does not surface those statuses, your customer will be the one to tell you, by phone, and unhappy.
On Kesla the payments dashboard with its statuses is part of the product, exactly like the booking itself. It is what lets the owner know, without me, whether a stay has actually been paid for.
A failed mobile payment does not always announce itself. If your back-office does not show the statuses, your customer will be the one to tell you.
Test the checkout before you put money through it
I validated the API responses with Postman and cURL before integrating them at all, then covered the purchase journey end to end with Cypress. On a payment flow, test coverage is not a matter of rigour: a lost transaction is a lost customer, and that trust does not come back.
The detail that costs half a day: the logos
Showing which payment methods you accept is not cosmetic. It is what tells buyers, before they type anything, that they will be able to pay with what they have. So I needed the logos for MTN MoMo, Orange Money, Wave, Airtel, M-Pesa, Visa, Mastercard, Google Pay and Klarna.
Finding good-quality, freely usable logos is harder than it sounds, and the usual libraries ignore the Mobile Money world entirely. I ended up using logos.lndev.me, built by Leonel Ngoya: 15,000 SVG logos, instant search, direct export into the framework of your choice, and above all the African operators are there. A few minutes instead of half a day.
A logo library built by a Cameroonian developer and used by developers worldwide is also an answer to the question of whether the African ecosystem produces tools, or only users.