Providers

A provider connection is your own account with a payment provider, held by Wajub and used on your behalf. Wajub does not resell anyone's rails: you sign with CinetPay or Flutterwave or MTN, you paste the credentials here, and the engine charges through them under your contract and your negotiated rates.

Everything the router knows about a connection is on its page under Orchestration, Providers. This page is what each field there does.

Connecting one

The wizard is four steps, and only the first two depend on the provider you picked.

Credentials. Every provider declares its own fields, because a CinetPay site_id has no equivalent at Stripe. The form is built from that declaration, so it asks for exactly what that provider needs and nothing else. Values are encrypted at rest and never returned to you in full afterwards.

Channels. Which of the provider's capabilities you want to route through this connection. Leave it untouched and you get everything the provider globally supports, minus the channels that need the provider to switch them on for you first.

Routing. The four numbers this page is really about: priority, weight, and your negotiated rate.

Review. Nothing is written before this step, and a connection test is available on the connection afterwards, which calls the provider with your credentials and tells you whether they work before a real payer depends on them.

What a connection is allowed to carry

Two lists narrow a connection, and both behave the same way: empty means everything, not nothing.

Channels. The router first checks the provider can technically carry the payment's channel, and then that your own channel list admits it. If you never set a list, the second check passes for every capability the provider has. Narrowing is opt-in.

Currencies. Same rule. An empty currency list accepts every currency the provider can settle.

The channel here is an exact slug, the same one the router works on: cm.mtn, sn.wave, ke.mpesa, card. There are no product-level values like mobile_money or bank_transfer anywhere in the engine, and picking a channel list is picking operator rails one by one.

Routing configuration

Four fields, and they do very different amounts of work.

Priority is the field to reach for when you know the answer. The other three only matter inside a tier, once priority has already grouped your connections.

A worked ordering: two connections both able to carry cm.mtn, one at priority 10 and one at 0. The first is always called first, whatever the second costs and however well it is performing. Move them both to 10 and the score starts deciding, which is when rates and live success rates begin to matter.

The catalogue, and what it means to be in it

The provider list in the Dashboard shows what you can connect. Three things have to line up before a provider can carry a live payment, and a provider can appear in the catalogue while missing one.

A provider with no driver is dropped from every candidate list before ranking, silently and by design. If you have connected something and it never appears in a routing decision, that filter is worth checking before the channel and currency ones.

Providers come in six types, and the type is what tells you the shape of the thing: aggregator, mobile_money, card, wallet, bank, crypto. An aggregator reaches many operators through one contract, which is why one aggregator connection can fill a whole column of the matrix. A direct mobile money connection reaches exactly one operator's rails.

Wajub also operates a house connection for Cameroon, covering cm.mtn and cm.orange, which is granted through an application rather than by pasting credentials. It behaves like any other connection once it is in place, priority and weight included.

How many you can connect

The ceiling is on your plan, and it is the one limit that shapes what orchestration can do for you.

Two connections is the minimum for a cascade to exist at all. On a single connection the engine still runs, still ranks, and still records a decision, but the list is one line long and a path failure ends the payment.

When a connection goes bad

Two mechanisms act on their own, on different timescales, and you do not configure either.

The health badge on the connection is a 24-hour read of your credited transactions through it, green from 95 %, amber from 80 %, red below, and grey until five payments have gone through. It is a judgement about the last day, meant for you.

The circuit breaker acts in seconds. Five path-side failures inside a minute on one channel and that route is dropped from candidate lists for five minutes, then probed once. It is scoped to your account, one channel and one provider at a time, so a connection failing on cm.mtn keeps serving cm.orange normally. Waterfall & fallback has the full behaviour.

What your integration can see

Your connections are readable from the API, and deliberately without the routing configuration.

The response gives each connected provider its id, slug, name, logo, type, active flag, and the channels actually available through it, which is the intersection of what the provider supports and what you enabled. Priority, weight, rates and credentials are not in it, and there is no endpoint that writes any of them.

Each entry of channels is the same object GET /channels returns, so one connection with six channels carries six of them. The sample below shows one connection and one of its channels in full.

Changes to a connection are pushed to your webhook endpoints, which is how a backend stays in step without polling that list.

Use the channel events rather than a hardcoded list if your checkout shows payment methods: they fire on the exact set the router will accept.

Asking for a provider that is not listed

Write to providers@wajub.com with the provider, the countries and the channels you need. A new provider needs a driver written and tested in the payment runtime, so it is a build rather than a configuration change, and the countries you name are what decides where it lands in the queue.