Payment Orchestration

An aggregator connects you to multiple providers behind a single API. An orchestrator goes further: it decides, transaction by transaction, which provider to use, in what order, and what to do in case of failure. This is the core of Wajub.

Aggregator vs orchestrator

The engine at a glance

For each payment, the orchestrator ranks every eligible provider and tries them in that order, falling back to the next one on failure — all in a few hundred milliseconds. Orchestration is always on: there is no opt-in flag on the payment request. It's driven entirely by how you configure your providers and rules in the Dashboard.

Building blocks

Orchestration Flow

How routing actually works

There is one algorithm — not a choice of "Smart" vs "Strict" modes. It runs in two stages:

1. Priority tier — dominant, always wins

Every provider you've enabled for your team (Providers in the Dashboard) has a priority integer. Candidates are grouped by priority and tried highest tier first, in full, before any lower tier is even considered. A lower-priority provider is never tried ahead of a higher-priority one — regardless of cost, rules, or live success rate. This is what gives you strict, predictable control: set MTN MoMo to priority 100 and Orange Money to priority 50, and Orange is only ever tried if every priority-100 candidate is unavailable or fails.

2. Tie-break score — only within a tier

Within a priority tier, candidates are ranked by a score made of three optional boosts:

Among candidates left tied after scoring, selection is weighted-random using each provider's configured weight — so you can split traffic (e.g. 70/30) between two equally-ranked providers.

In short: priority is your hard ordering; rules, cost, and telemetry only settle ties within the tier you've placed a provider in.