Routing

Network → Routing decides which partner a payment goes to.

There is no shadow mode here

Unlike risk rules, a routing rule in force routes matching payments immediately, to the partner it names. There is no “watch what it would have done for a fortnight”, and a mistake shows up as failed transactions rather than as a report.

Precedence and priority are different

Both are shown, because showing one without the other inverts the meaning.

	What it is	Which wins
Precedence	Derived from scope.	Higher wins — a merchant rule outranks a global one.
Priority	Ordering within the same precedence.	Lower is tried first.
Weight	Used only among rules tied on priority.	Higher is drawn more often.

Priority and weight run in opposite directions. That is the single most common misconfiguration on this page.

Three reasons a rule carries no traffic

Carries traffic answers it in one column: “A rule can be active and still carry nothing: an unservable rail, a down partner, or a live override on the partner.”

Pill	Means	It is a…
Yes	Active and carrying traffic.
No adapter in this build	This build’s adapter can’t carry the rule’s rail, so every transaction routed here fails.	deploy problem
Skipped — partner down	The resolver skips the rule entirely.	operational problem
Retired	No longer in force.

A live override on the partner is not shown here. The overrides panel below the table is where that shows up.

The unservable count is reported by the platform itself rather than counted from the page, so it covers rules you cannot see on this page.

The rules table

Column	Notes
Rule	The label, with direction, channel and currency.
Partner	Where traffic goes. A degraded or down pill appears beside it only when the partner is not healthy.
Scope	Merchant (with the merchant’s code) or Global. “Precedence is derived from scope: a merchant rule outranks a global one.”
Tried	p{precedence}/{priority}·w{weight}: “Precedence first (higher wins), then priority (lower is tried first), then weight.”
Amount band	The floor and ceiling it applies to, or no floor / no ceiling.
Failover	“Failure classes worth another partner. Empty means no failover.”
Carries traffic	See above.
Effective from, Retired	Hidden by default.

Rule, Partner and Failover keep a minimum width, so on a narrow screen the table scrolls sideways rather than cutting them short.

Retired rows stay in the table. There is no delete in routing — traffic was routed by retired rules historically and transactions carry the rule id, so the record has to stay readable. “Which rule sent this payment to that partner” is the first question asked when a payment goes somewhere surprising.

Creating a rule

“Live traffic follows this as soon as it is in force.”

Field	Notes
Label	“How this rule is named in a routing decision log. Make it say what it is for — this is what somebody reads when working out why a payment went where it did.”
Applies to	Global, or one merchant.
Merchant	When merchant-scoped.
Scope detail	Shown for a global rule, to say there is nothing more to pick: “a global rule applies to everybody.”
Environment	“The partner list below is filtered to this environment, because routing joins the two.”
Direction	Collection or payout.
Channel	—
Currency	—
Partner	The rail.
Priority	LOWER IS TRIED FIRST. 0–1000.
Weight	“Used only among rules TIED on priority, and here higher is drawn more often. The two run in opposite directions.”
Partners this chain may try	1–5. How far a failover chain goes.
Pause between attempts (ms)	0–30000. “A customer is waiting through this.”
Amount floor	Blank for no floor.
Amount ceiling	“Blank for no ceiling. A payment outside the band falls to the next matching rule, and to nothing if there is none.”
In force from	“Blank means now. A future time STAGES the rule: it exists, carries nothing, and starts on its own.”
Internal notes	—
Why	The audit log.

An amount band with no fallback is a refusal

A payment outside every matching rule’s band routes to nothing. If you add a banded rule, make sure something unbanded, or a wider band, sits below it.

Staging a rule with a future start time is the closest thing routing has to a rehearsal: it lets you prepare a change for a known window rather than making it at the moment somebody is free.

Changing a rule

Label, priority, weight, chain length, pause, and:

Control	Notes
Considered by routing	“Switching this off takes the rule out of routing WITHOUT retiring it, so it can be switched back on. Retiring is the permanent version and sets an end date.”
Why	“The audit log records the band before and after, so a widened band is traceable.”

Retiring a rule

Field	Notes
Retire at	“Blank means now. A future time schedules it, which is how a partner is wound down over a planned window rather than at the moment somebody happens to press this.”

Overrides — the emergency lever

“This vendor is failing every transaction. Stop sending them anything, now.”

An override diverts traffic away from a partner wholesale. It exists because editing a priority ladder under pressure is how a second incident gets created.

It is the only routing write on this console that needs no second operator, and that asymmetry is deliberate: the thing that stops the bleeding must not be gated behind the hardest thing to arrange at 03:00.

Field	Notes
Environment	“The partner list is filtered to this, because an override is matched on environment.”
Partner to divert away from	—
Direction	“Blank diverts both. An incident usually affects one.”
Channel	“Blank diverts every channel.”
Duration	Capped at twelve hours, enforced by the database “so a workaround cannot become policy”. The chosen duration is previewed as an actual clock time before you submit.
What incident is this for	“Goes in the override row AND the audit log, so whoever finds this at 05:00 knows what it was for.”

The live overrides panel leads with how long each one has left.

An override that lapses unnoticed sends live traffic back

To a vendor nobody has re-checked. The twelve-hour ceiling is the entire justification for skipping dual control, so the expiry is the loudest thing on each row — and following up before it lapses is the operator’s job, not the platform’s.

An override cannot send traffic somewhere particular

It excludes the diverted partner and then orders the survivors normally, so diverted traffic goes wherever the configured rules send it.

Overrides created before this was enforced may display a target partner that does not apply. Those rows are marked, and the lookup below is what proves where traffic is really going.

Cancelling an override takes a reason — “usually that the incident is over.”

The lookup

The most useful thing on this page: it answers where a payment would actually go right now for a given partner, environment, direction and channel.

Use it:

• after creating or changing a rule, to confirm the ladder resolves the way you intended;
• after raising an override, to see where the traffic actually went;
• when a payment went somewhere surprising, before changing anything.

It sits beside the rules rather than behind a route of its own, because the only time it matters is while you are looking at this screen.

A routing change, safely

1. Look up the current resolution for the traffic you are about to change.
2. Make the change — staged for a window if it is not urgent.
3. Look it up again and confirm the answer moved the way you expected.
4. Watch Transactions and the partner’s Performance tab for the next few minutes.
5. If it is wrong, raise an override rather than editing the ladder again under pressure, then fix the rules calmly.