Smart Route
Routing scored from measured success rates, cost and latency per connector, with a circuit breaker that takes a failing rail out before your customers find it.
Merchants who lose sales to failed payments, and developers who would otherwise build failover themselves.
Part of the platform itself: it is present wherever BitriPay runs.
The problem
Most integrations hard-code one provider. When it degrades, every payment degrades with it, and the business finds out from customers rather than from a dashboard.
How it works
- Candidate connectors are assembled from what can actually carry this payment.
- Each is scored on measured success rate, total cost, and observed latency.
- The circuit breaker removes a connector that is failing, and lets it back gradually once it recovers.
- A merchant policy can bias the choice towards cheapest, fastest or most reliable.
What you can check
Facts about the running platform rather than adjectives. Each one is visible in the product, the API reference or the ledger.
- Scores come from telemetry kept in fifteen-minute buckets over twenty-four hours, optionally keyed by amount band and prefix, rather than from a static preference list.
- The breaker moves closed → open after consecutive faults → half-open after a cooldown → closed on the next success, so a recovering rail is tested with one payment rather than all of them.
- Health is a state per connector — healthy, degraded, unavailable, maintenance — derived from the circuit, the last probe and recent success.
- Failover only happens for errors that guarantee no money moved; anything ambiguous triggers a status check first.
- A merchant can bias routing towards cheapest, fastest or most reliable per payment.
What it costs
Included. You pay the rate of whichever rail carried the payment, and the dashboard shows which one did.
Questions
Could a retry charge my customer twice?
Failover happens only for errors that guarantee no money moved. For anything ambiguous — a timeout, an unknown code — the status is checked first. Not retrying is better than retrying into a double charge.
Can I force a particular rail?
You can bias the routing policy towards cheapest, fastest or most reliable, and restrict which rails a payment may use. What you cannot do is force a rail whose breaker is open, which is the point of having one.
How do I know which rail was used?
Every payment records the connector that carried it, along with the attempts before it. The dashboard shows the route a payment actually took, not the one it was supposed to take.
Read next
The gateway API
A payments API whose documentation is generated from the same table that serves the requests, so the reference can never describe an endpoint the platform does not have.
Hosted checkout
A checkout that offers the payer only the rails that can actually complete their payment, decided at the moment they arrive rather than listed hopefully on a page.
National switch connection
An adapter written against an internal contract rather than a protocol, with a simulator that reproduces the awkward cases — a timeout after a financial effect, a contradictory late rejection — before a real connection exists.