Why do African payment aggregators neglect developers?

To accept an online payment in Africa, you almost always go through a payment aggregator (a PSP, payment service provider), a middleman that connects the merchant’s site to mobile money operators and bank cards. Plugging directly into a telco’s mobile money API is possible, but it’s nearly out of reach for an ordinary merchant: very little public documentation, rarely a sandbox. Picking that middleman falls on the developer or the agency who will integrate it, maintain it, and live with its flaws for years.

I’ve integrated several, on client projects and on my own products. Here I compare what each one gives the person integrating it. And I still can’t understand why companies with technical teams, that have been around for years, ship such an uneven developer experience (DX).

What a good aggregator ships#

To me, a serious aggregator gives five things to whoever integrates it:

• public documentation, readable before you even open an account;
• a sandbox, to test without real money;
• signed webhooks (the payment notifications sent to your server), with a signature that proves the confirmation really comes from the provider;
• official SDKs (code libraries), so you can plug your app in without rewriting everything;
• public pricing, and ideally a few figures like success rate or uptime.

Stripe set this standard more than ten years ago. It’s documented, and African players already meet it, like Paystack, Flutterwave and several regional aggregators. So we can expect it here too. Here’s the gap, provider by provider.

Provider by provider#

PayGate#

With PayGate, I could only read the documentation once my merchant account was activated, after sending the company paperwork and waiting for approval. Before that, there’s nothing to read, so nothing to compare. Once inside, the dashboard fits in five screens, the API key is shown in plain text at every login, and the confirmation webhook arrives unsigned. Bank cards have been announced as “coming soon” on the homepage since 2016 and still aren’t available. The operator logos on the site still show brands that no longer exist.

For the integrator, that means testing in production for lack of a sandbox, and writing your own check that each confirmation really comes from PayGate. In ten years the product hasn’t moved, while the standard kept rising.

Qosic#

With Qosic, the documentation is public, the status codes are clear and pricing is listed, so getting started goes well. It gets harder after that. The confirmation webhook isn’t signed and carries an amount you shouldn’t trust, while the reference confirmation returns no amount at all. And until the transaction settles, you have to poll (hit their API in a loop) to learn the outcome.

So I had to store the order amount on my side, reconcile every payment by hand and maintain polling that other providers make unnecessary.

CashPay (Semoa)#

On paper, CashPay’s offer is broad: bank cards, mobile money, wallets, several countries. On the integration side, it’s much fuzzier. The documentation boils down to a Postman collection, with no guide walking through the flow end to end. You can’t do anything on your own online: you have to contact their team, and most things unlock after signing a contract. The sandbox and the dashboard exist, but you only get access once your account is created. I couldn’t find clear pricing either.

In practice, you evaluate from sample requests, and you only learn the real cost after the sales conversation.

FedaPay#

FedaPay comes closest to the standard: public documentation, self-service sandbox, official SDKs, card support. I migrated a project to it in 2021, when PayGate was no longer enough, and saw the difference within the first hour. The provider did its part, and I didn’t have to write workarounds to cover its gaps. Integration cost is low, and it’s the one I compare the others to.

Kkiapay#

I plugged in Kkiapay recently for a test. The sandbox works with no setup, the test numbers are public, and there are SDKs for most languages plus e-commerce plugins. I was up and running in an afternoon, without talking to a salesperson. The standard I described above, a company from Benin meets it.

Wave#

Wave isn’t an aggregator but a mobile wallet, and technically it’s the most solid I’ve seen. Its documentation is public, you can read everything before opening an account, and it keeps a dated changelog going back to the API launch in 2022.

You can tell the team thought about the person integrating. Webhooks are signed with HMAC-SHA256, with a timestamp that protects against replay. Each API key can be restricted to specific APIs and IP addresses, and you can require your own calls to Wave to be signed too. Errors come back as JSON with a readable code and message. The docs are also upfront about what can go wrong: a webhook can arrive twice, late or out of order, and Wave retries for three days if your server doesn’t respond. Usually you only find out about that kind of thing in production.

Two gaps, though. No sandbox is documented: the examples use production keys, and you need an approved Wave Business account before your first call. There’s no official SDK either, just examples in cURL, PHP, JavaScript and Java.

So on webhook signing, a company from another category does better than aggregators whose whole business this is, which makes it hard to blame their gaps on a lack of resources.

The comparison#

I don’t give an overall score, because the weight of each criterion would be arbitrary. The table only says whether each item is there, partial or missing, which a developer can check for themselves.

Table based on my integrations and each provider’s public documentation. The criterion-by-criterion detail, with sources, is in the open registry Afrotools. If a cell is wrong, tell me.

What missing building blocks cost#

None of these building blocks is heavy to ship. Public documentation fits on a web page, a sandbox needs a set of fake data, and standard libraries can sign a webhook in a few lines. For a company that already employs developers, it’s a matter of days of work.

When they’re missing, someone else pays. The integrator writes defensive workarounds, or recommends another provider to the next client. The merchant sometimes pays more for a service that gives them more work. As for the incumbent, its reputation, operator referrals and years of relationships protect it until a competitor shows up with a better integration. When that happens, the advantage can melt fast.

Why they don’t do it: three hypotheses#

I don’t have the answer, only three hypotheses, from most to least likely.

The first is the lack of pressure. When operators send customers to an aggregator by default, winning over developers brings no visible return. It’s the simplest explanation, and probably the main one.

The second is an operations culture more than a product culture. As long as money comes in and it runs, nobody touches anything, and the developer integrating is seen as an implementation detail rather than a user.

The third comes from how they sell. A provider that signs clients in meetings doesn’t need a stranger to succeed alone with an integration from public docs.

None of these reasons is technical, they’re choices of priority. That’s the question I’m asking the companies mentioned here, without putting them on trial: what makes these building blocks less of a priority than the rest?

Why I’m writing this#

I’m neither an end client nor a competitor of these companies. I’m an African developer who has integrated them, and I’d rather see them keep this market than lose it because engineering was neglected. The market is opening up, and a historical lead won’t be enough.

Everything here comes from my integrations and public documentation. It’s a developer’s field report that any integrator can reproduce on their side: I ran no security testing. When I write “unsigned webhook”, I’m describing what I received while integrating, not a flaw I went looking for. And if a fact is wrong, I’ll fix it in the article, visibly.

What have you integrated?#

I’ve only integrated a small share of the continent’s payment methods. There are dozens more from one country to the next, and many of you probably have experience I don’t.

So tell me. Which PSP or payment method have you integrated, and how did it go? On the product side: account opening, pricing, support, payout delays. On the tech side: docs, sandbox, webhooks, SDKs, whatever cost you time. A good surprise interests me as much as a headache. And if I missed a recent feature from one of the providers here, or you made an integration work where I describe the opposite, say so too: I’ll correct it.

Reply in the comments under the post that shares this article, or write to me directly.

If you integrate African APIs, also take a look at Afrotools, an open source registry of African API specs, verified against the live APIs, that anyone can contribute to.