Providers

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

Everything routing uses 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 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. A payment goes through the connection only when the provider can technically carry the payment's channel and your own channel list admits it. If you never set a list, every capability the provider has is admitted. Narrowing is opt-in.

Currencies. Same rule. An empty currency list accepts every currency the provider can settle. You set it in the connection wizard and on the connection's page, under Currencies.

The channel here is an exact slug, the operator channel payments are routed on: cm.mtn, sn.wave, ke.mpesa, card. No payment is routed on product-level values like mobile_money or bank_transfer, 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 for every payment. When the answer depends on the country, the channel, the currency or the amount, a routing rule says it more precisely and is applied first, and a channel policy can order one operator channel on its own. Without a channel policy, the other three fields only matter inside a tier, once priority has already grouped your connections. With one, the rate and the fixed fee also feed its Least cost objective and its cost ceiling, and weight shares traffic between the connections it leaves equal.

A worked ordering: two connections both able to carry cm.mtn, one at priority 10 and one at 0, no rule and no policy on the channel. The first is always called first, whatever the second costs and however well it is performing. Move them both to 10 and cost and recent success start deciding, which is when your 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.

If you have connected a provider and it never appears in a routing decision, run its channel, currency and amount through the routing simulator, on a Growth plan or above: it names the reason each connection was left out.

Today you can connect 24 providers: the Wajub rail (by application, below), Stripe, PayPal, Flutterwave, Paystack, PawaPay, CinetPay, InTouch, FedaPay, Kkiapay, Maviance, My-CoolPay, Monetbil, Campay, Neero, Notch Pay, Taramoney, Fapshi, Nokash, MTN MoMo, Orange Money, Wave, Djamo and Express Union Mobile Money. The others in the catalogue are marked Coming soon and cannot be connected yet.

Connections are live, so a live connection refuses a provider's test keys: a Stripe or Paystack key starting with sk_test_ or pk_test_, a Flutterwave key containing _TEST-. The Dashboard refuses them when you save, because these providers answer a connection test with a test key and the connection would look healthy while every real payment failed.

When Wajub puts a provider in Maintenance, routing skips every connection to it until it is back, and the next connection takes the payment. The decision records the skip with the reason provider_in_maintenance. Only an Available or Beta provider takes payments: one marked Coming soon or Disabled is skipped the same way, with the reason provider_unavailable, even if a connection to it is still active.

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, the Wajub rail. It is granted through an application under Orchestration, Wajub rail rather than by pasting credentials, and only once your account is verified. You pick the channels, review the proposed rates, and sign the agreement in the Dashboard. Wajub then reviews it: the application is approved, approved for some of the channels only, or rejected, and the signed agreement can be downloaded once it is accepted. One application is reviewed at a time, and you can apply for more channels afterwards. Once in place, the rail behaves like any other connection, 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.

The Wajub rail does not count against that ceiling: on Pay as you go you can hold two connections of your own and the Wajub rail.

Two connections is the minimum for a cascade to exist at all. On a single connection Wajub still records a routing decision, but the list is one line long and a failure on the provider's side 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 within minutes. When a connection keeps failing on one channel, Wajub pauses it on that channel for a few minutes and brings it back automatically once it works again. Only your account and that channel are affected, so a connection failing on cm.mtn keeps serving cm.orange normally. Waterfall & fallback has what you see while it happens.

One thing only you can fix is flagged on the connection itself. When it has no credentials for a channel, or the provider rejects its key, the connection shows Connection refused in the list, the provider page shows the error with Fix the connection, and your team gets one email about it, within about five minutes. Another comes only if the connection is flagged again after the flag cleared. The flag clears when you save different credentials, when a connection test passes, or on the next payment the connection takes. Waterfall & fallback covers what such a connection does to a payment.

What your integration can see

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

The response gives each active connection its id, slug, name, logo, type, an is_active that is therefore always true, 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, with every field of it, so one connection with six channels carries six of them. The sample below is abridged to one connection and a few fields of one channel.

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 Wajub will route on.

Asking for a provider that is not listed

Write to providers@wajub.com with the provider, the countries and the channels you need. Adding a provider is development work on our side, not a configuration change, and the countries you name help us prioritise it.