Payments
One failing provider should not be a failed deposit
Providers degrade quietly and recover without telling you. Routing exists so that the client attempting to fund at that moment never finds out.
See it live
The routing table, not just the promise
Method, currency, country and live success rate all feed one configuration, and every one of those weights is something you can open and read.
Retries
The part that turns a good idea into a double charge
The same request, never a second charge
A retry carries the original idempotency key. If the first attempt actually succeeded and only the response was lost, the retry returns that result rather than creating a second payment.
Only retry what is worth retrying
A network timeout is worth another attempt. An explicit decline for insufficient funds is not, and retrying it just annoys the client and the provider.
Fail over, do not just repeat
Where the first provider is the problem, the second attempt goes somewhere else. Repeating the same request to the same failing endpoint is not a retry strategy.
Provider health
Routing reacts to what providers are doing, not what they promised
Weight shifts away from a degrading provider automatically
Slow responses are treated as early failure evidence
A spike in one reason code is surfaced, not averaged away
Provider removed from routing until it recovers
FAQ
Provider routing: common questions
6 short answers to what teams ask before a demo.
No. Your existing provider relationships and commercial terms stay yours. Routing sits above them and decides which of your providers gets each attempt, which is a different thing from replacing them.
From the method, currency, country and amount, then weighted by measured success rate and cost. The rules are yours to set and inspect — routing that cannot be explained afterwards is not a feature.
Every attempt carries an idempotency key. If the original request actually succeeded and only the response was lost, the retry returns the original result instead of creating a second payment.
No, and that matters. Timeouts and transport errors are retried, usually against a different provider. An explicit decline is not — repeating it wastes the client's time and damages your standing with the provider.
Weighting shifts continuously as success rates move, and a hard outage removes the provider from routing until it recovers. The point is that the first client to hit the problem is not also the hundredth.
Yes. The chosen provider, the routing reason and any earlier failed attempts are all attached to the payment record, so a support question or a reconciliation query has one place to look.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistBring your provider mix
We will map your current providers against method, currency and geography and show you where attempts are going to the wrong one.