If you collect payments in Africa, you already know the problem: every operator has its own API, every country has its own leaders, and an integration does not carry over from one rail to the next. That is not the expensive part.
The expensive part is the day your only connection on a channel stops answering. Your code is fine, the customer is ready to pay, their wallet is funded and nothing happens. Collections stop when the connection does, for the day, across a whole country.
Wajub exists so that day costs you nothing. An outage should never cost you a sale.
A layer, not one more middleman
Wajub sits between your application and your payment providers. You integrate one API; behind it, your connections stay yours.
That is a design decision, not a commercial one: the provider accounts you plug in are your accounts, with your contracts and your negotiated rates. Wajub does not replace them, does not step into the relationship, and does not need you to leave anyone to be useful. The providers already serving you well keep serving you they simply gain a stand-in on the days they do not answer.
The most visible consequence of that choice fits in one line: there is no provider field in the API. There is no way to add one. Your code asks for a payment; it does not name who should carry it, and it should not grow a dependency on the answer.
How a decision gets made
For every live payment, the engine builds the list of connections that can carry this exact payment, ranks it, tries the first, and steps down when one fails on the way out.
Three stages, in this order.
Filters. The resolved channel cm.mtn, sn.wave, card, the currency, the state of the connection, whether a driver exists, and whether the circuit is open. A connection that fails any of them is simply not in the list.
Priority, which you set. It is absolute: the top tier is tried in full before the next is touched. It is the one control that is not a suggestion.
A score, which breaks ties inside a tier. Your routing rules are worth 1000 to 3000 points, least cost 200, and the success rate observed over the last fifteen minutes 50 or 25. Put differently: when you know better than the numbers, write a rule and it wins; otherwise, let the numbers decide.
Then the cascade. A path-side failure, timeout, 5xx, rejected credentials steps down a rung, up to three providers. A refusal from the payer stops it outright: asking a second provider would put the same question to the same person.
And a route that keeps failing is taken out of rotation: five failures in sixty seconds, five minutes aside, then one probe attempt. Payer-side failures do not count an empty wallet is not evidence that an operator is having a bad day.
Every decision is recorded, payment by payment, with each candidate’s score and the reason behind every skip. You do not take our word for it: you open the routing log.
What surrounds it
Twelve products, which sort into four jobs.
Collect: the Payments API, a hosted payment page, payment links with no website at all, and components you embed in your own pages in JavaScript, React, Vue or Svelte.
Pay out : Payouts to mobile money, from your balance or from your own provider account.
Bill and control : invoices your customers pay online, tax computed before you charge, and a risk score on every live payment before a provider is called.
See what happened : the Dashboard for activity, Konsole for the routing log, API logs, events and the webhook tester.
One set of keys, one bill, the same signed webhooks throughout. Start with the product you need and add the others without a new integration.
Coverage, with numbers and a date
Vague figures serve nobody. As September 2026: 23 countries, 68 channels, 24 connections.
The number that actually matters for what we sell is the fourth: 42 of those 68 channels have at least two connections able to carry them. That is where the cascade has something to recover. On the other 26, only one connection exists in the catalogue today, and failover has nothing to offer until that changes.
We would rather tell you than let you find out on a Tuesday morning.
What Wajub does not do
The most useful part of this page.
Wajub is not a payment institution, is not an aggregator, and does not hold funds. Collection and settlement are provided by licensed providers. Settlement times are theirs.
Orchestration does not guarantee that a refused payment will be accepted elsewhere. It guarantees that a provider-side outage does not end at the first closed door. A customer with no balance is still a customer with no balance at the third provider.
The sandbox routes nothing. It resolves a single synthetic provider: no candidate list, no rules evaluated, no circuit breaker. It is there to validate the shape of your integration. Routing is tested live, on small amounts and we would rather write that here than let you sign off on rules that were never executed.
Routing rules are a paid feature, from the Growth plan up, and live only.
Tax calculates, but does not file or remit. The tax ledger is kept and the reports are there; filing remains yours.
What to judge us on
Not a wall of logos.
On an engine whose every decision is logged, payment by payment. On documentation that publishes its own blind spots read what we write about the country field on a routing rule; we documented it rather than let a merchant lose a day to it. And on coverage you can verify channel by channel before signing anything.
For a platform asking to carry your collections, that is the only kind of proof worth anything.
Getting started
The sandbox is free, with no time limit. One key, one integration, and you will have the shape of the API in an afternoon.
Then go live on one channel, with two connections and small amounts, and watch the routing log. That is the test that counts: the one where you see, on your own payments, what happens when the first door does not open.