Routing
Which providers were considered for a payment, in order, and why.
When a payment has more than one possible provider, the orchestrator ranks them and takes the first. The Routing view is the record of that ranking: every candidate, its score, the ones that were skipped, and the attempt chain that followed.
It answers the question that has no other answer: why did this payment go through that provider?
Live only
Routing is gated to live mode. Sandbox payments do not go through provider selection, so a sandbox account has nothing to show here.
Filters
| Filter | What it matches |
|---|---|
| Search | The payment id |
| Channel | cm.mtn, ci.orange, and the rest |
| Provider | The one that won |
| Date start, date end | Whole calendar days |
| Outcome | fallback, circuit_skip or no_candidate |
The outcome filter is the shortcut worth knowing.
| Outcome | Means |
|---|---|
fallback | More than one candidate was ranked, so the waterfall had somewhere to fall |
circuit_skip | At least one provider was skipped because its circuit breaker was open |
no_candidate | Nothing was eligible. These are the payments that failed before any provider was called |
Filtering on no_candidate over a week is the fastest audit of your own configuration: every row
is a payment you could not have taken.
What a decision record carries
| Field | Note |
|---|---|
| Payment | The id, the channel, the amount and the currency |
country_blocked | True when a country restriction stopped the payment before any candidate was loaded |
circuit_skipped | Providers removed from the race, each with the reason |
candidates | The ranked list |
| Attempts | The actual provider calls that followed, in order |
Each candidate carries the whole arithmetic behind its position.
| Field | What it is |
|---|---|
rank | 1 is the one that was tried first |
priority | The base priority of that provider on your account |
rule_id, rule_boost | Which of your routing rules matched, and what it added |
is_least_cost, cost_boost | Whether it was the cheapest, and what that was worth |
telemetry_boost | Adjustment from that provider's recent success rate |
tiebreak_score | What separated two otherwise equal candidates |
weight | The final figure the ranking used |
Reading these in order tells you whether a payment took a rail because of your rule, because it was cheapest, or because the provider you expected has been failing lately.
Three things to look for
A rank 1 you did not expect. Compare rule_boost and cost_boost. A least cost boost can
outrank a rule you thought was decisive.
A provider missing from the candidate list. It was not skipped, it was never eligible. The cause is upstream of routing: currency, channel or country support, or the provider not being enabled on your account.
A provider in circuit_skipped. Its circuit breaker was open, meaning it had been failing
enough to be taken out of the rotation. The reason is on the entry.
`country_blocked` is not a provider decision
It is an account level restriction, checked before any candidate is loaded. When it is true the candidate list is empty and no provider was ever contacted.
The attempt chain
Under the ranking sits what actually happened: one row per provider call, in order, with the outcome of each. A payment that succeeded on the second candidate shows the first one's failure above it, which is the whole point of a waterfall you can audit.
Routingtrx_CSUGajfv9xh0XQ5wu2lx
payment.created12:31:48.001
25,000 XAF, channel cm.mtn
route.evaluatedmomo-cm-mtn-first12:31:48.044
Rule "MoMo CM, MTN first" matched
provider.attempt.failedMTN MoMo12:31:48.901
MTN MoMo returned a 503 error
route.fallbackwaterfall12:31:49.220
Automatic waterfall fallback to next provider
provider.attempt.succeededOrange Money12:31:50.130
Payment accepted
payment.succeeded12:31:50.140
trx_CSUGajfv9xh0XQ5wu2lx, 1 940 ms over 2 attempts