Never-down payments

RohoPay routes every transaction through a smart router with a circuit breaker. If the channel currently handling your transaction is slow, erroring, or offline, RohoPay automatically fails the request over to the next healthy channel — usually without your code noticing.

This is what lets us promise "never down": a single channel outage should never block your customers from paying.

How it works

1. Automatic routing (default) — RohoPay routes each mobile-money transaction through the most reliable available channel, with automatic failover to a backup channel if the primary is temporarily unavailable — this is deterministic, not probabilistic. Card payments always go through RohoPay's card processing network. Which channel handles a given transaction is an internal RohoPay implementation detail and may change without notice.
2. Weighted routing (alternate, togglable) — a smooth weighted round-robin mode also exists as an internal option, but it is not the default.
3. Circuit breaker per channel — each channel has its own breaker, so a degraded channel is automatically taken out of rotation until it recovers.
4. Automatic failover — if the chosen channel returns an error, the router retries the same request through the next available channel.
5. Self-healing — after a cooldown, the breaker lets a few probe requests through (half-open). If they succeed, the channel is restored to the pool; otherwise it stays open.

When a payment is served by a fallback channel, the API response includes a failover_reason field so you can see what happened in your logs, e.g. "Primary channel returned a timeout; retried with backup channel".

What this means for you

• No code changes required — failover is transparent at the API level.
• No configuration required — routing, failover, and circuit-breaking are managed entirely by RohoPay; there's nothing to set up or tune on your side.
• Always a path to "paid" — a degraded mobile-money channel won't stop card payments, and vice-versa.
• Observable — every fallback is logged and surfaced via failover_reason, so you can track reliability in your own dashboards.