Orchestration
Route every payment to the provider most likely to approve it.
Rules you write, health PediWave measures, and a cascade that retries only when it is safe. Every decision can be explained, and simulated before it happens.
How it chooses
Four parts, one decision per payment.
A rule picks who may take the payment. Scores put them in order. The cascade decides whether a second try is safe. Circuits take a failing provider out of the running.
Rules
Match on rail, currency, card country, amount, card brand, merchant category and time of day. Rules run in priority order; the first that matches gives the list of providers allowed to try.
Smart scoring
Each candidate is ranked on its recent success rate for that rail, card brand and issuer, its response time, and its cost. You set how much each counts.
Cascade
If the first provider is unavailable or returns a retry-safe error, the next one tries. Never after insufficient funds, a stolen card, fraud, failed authentication or a limit, and never on an unknown.
Coming soon: Circuits and kill switches
A provider that keeps failing is taken out of routing automatically and tested again before traffic returns. Switch off a provider, rail, merchant or country with one audited flag, or drain a provider so it finishes what it started and takes nothing new.
// 10:00:00 confirm → attempt att_…01 on con_provider_a
// 10:00:30 no answer in 30 s: outcome unknown, no cascade
event payment_intent.processing
{ "status": "processing",
"reason": "awaiting_connector" }
// 10:01:30 PediWave asks Provider A for the status
POST /v1/payment/intents/pi_01J9ZK…/sync
// Provider A: the authorisation went through
{ "id": "att_01J9…01",
"connector": "con_provider_a",
"status": "authorised" }
event payment_intent.succeeded // one charge, no second tryTimeouts
A timeout is not a decline.
When a provider does not answer within 30 seconds, PediWave marks the attempt as unknown and asks that provider what happened. If the payment went through, it carries on as normal. If it did not, the next provider may try. If the provider cannot be reached at all, the payment stays in processing while PediWave keeps asking, and you are told why.
- Enquiries every minute for ten minutes, then every fifteen minutes.
- A late success on the first provider after the second one approved is voided automatically, and operations is alerted.
- Your code sees
processing, never a falsefailed.
// Request: { "payment_method_types": ["card"], "currency": "NGN",
// "bin": "506099", "amount": 2500000 }
{
"rule": "rr_cards_ng",
"strategy": "smart",
"ranked": [
{ "connector": "con_provider_a", "score": 0.91,
"reasons": { "success_rate_15m": 0.96,
"cost_percent": 1.4, "p95_latency_ms": 1800 } },
{ "connector": "con_provider_b", "score": 0.88 },
{ "connector": "con_provider_c", "score": 0.84 }
],
"cascade": { "max_attempts": 2,
"on": ["issuer_unavailable", "connector_error",
"timeout", "do_not_honor"] },
"three_ds": "risk_based"
}Simulate
See the decision before it happens.
Send any payment's details to the simulate endpoint and PediWave returns the rule that would match, the candidates in order, each one's score and the reasons, without creating anything. After a real payment, the same record sits on every attempt, so you can always answer "why did this go to that provider?".
- Rule changes go from draft to live only after a second person approves them.
- The previous version of every rule is kept, so a change can be rolled back.
- Every attempt records its rule, its candidates and the reason for the choice.
Cards · NGN · 50 / 50
Provider A
Approved
94.2 %
Attempts 1,204
Provider B
Approved
93.6 %
Attempts 1,197
Cap 50 % of traffic · cards only · never payouts
Experiments Coming
Test two providers on a slice of real traffic.
Split card payments between two providers and compare approval rates on your own customers. Each payment is assigned by its id, so the split is stable and repeatable. Experiments are capped at half your traffic, measure card approvals only, and never touch payouts.
- Set the split on the rule; switch it off by editing the rule.
- Results per provider in the dashboard.
- Provider A 71 % Circuit open
- Provider B 95 % Closed
- Provider C 93 % Closed
10:14 connector.degraded · Provider A · traffic moved to Provider B
Health Coming
A failing provider loses traffic on its own.
PediWave tracks each provider's success rate and response time over a rolling fifteen minutes. As a provider degrades, its score falls and new payments go elsewhere, with no change to your settings. After repeated retry-safe failures its circuit opens; PediWave then tests it with a single payment each minute, and only after several succeed does traffic return, in steps.
- You and PediWave operations are alerted with
connector.degradedandconnector.recovered. - Drain a provider to keep it out until its own incident report is in.
- Card Coming
- Transfer , available
- USSD Coming
- QR Degraded
- Mobile money Coming
- Wallet , available
- Voucher , available
- Agent cash Coming
- POS Coming
- Offline tap , available
Checkout now shows: Transfer, Wallet, Voucher, Offline tap QR
Local rails
Every rail is scored on its own.
Transfer, QR and wallets are tracked separately, so trouble on one never takes down the others. When a rail is degraded, hosted checkout stops offering it and the customer pays the same intent another way. Your page can ask what is available for an intent right now, with the reason for anything that is not.
payment_method_optionslists each rail withavailableand a reason such asrail_degraded.- Card health is tracked per brand and issuer, not as one number.
- Mobile money connectors are coming.
Safety
Safety, written down.
These rules apply to every payment on every rail, and they are the same in the sandbox.
| When this happens | PediWave does this |
|---|---|
| A provider declines with a real answer: insufficient funds, a stolen or picked-up card, an invalid card, fraud, failed authentication, or a risk or limit refusal | Stops and returns the decline code. These are answers, not outages, so no other provider is tried. |
| A provider is unavailable, returns a connector error, or the issuer is unavailable | Tries the next candidate, up to the rule's limit, as a fresh attempt linked to the first. |
| A provider does not answer in time | Marks the outcome unknown and asks that provider for the status. A second provider may try only once the first confirms no money moved. |
| The first provider later reports a success after a second one already approved | Voids the first automatically and alerts operations. The customer is charged once. |
| Your server retries a request after a dropped connection | Returns the first answer with Idempotency-Replayed: true. The same key with a different body is refused with 409. |
| The ledger behind PediWave is briefly unavailable | Answers reads from the last known state, marked as stale. Refuses writes with 503 and a time to retry, never a false success. Offline taps keep working, because they need no provider. |
| Someone changes a routing rule | Keeps it in draft until simulated, submitted and approved by a different person. The previous version is kept for rollback, and every attempt records which rule it used. |
| A provider's credentials are needed | Reads them from a separate vault path for that provider and environment. The routing engine never sees them. |
Connectors
The providers behind the routing.
Acquirers, banks, a national switch and mobile money operators, each scored on its own. More are added as contracts are signed; providers marked Coming are not yet connected.
Cards and payment processors
- Card acquirer A Coming
- Card acquirer B Coming
- Card acquirer C Coming
- Card acquirer D Coming
- International acquirer A Coming
- International acquirer B Coming
Banks and virtual accounts
- Partner bank A
- Partner bank B
Switch
- National switch
Mobile money
- Mobile money operator A Coming
- Mobile money operator B Coming
- Mobile money operator C Coming
Providers are listed by type until each partnership is announced. Card routing goes live with card acceptance, once our PCI DSS assessment completes; the card examples on this page run in the sandbox today.
Questions, answered.
Something else? Talk to sales: we reply within one business day.
Can I pin a provider?
Yes. On any payment you can prefer providers, exclude providers, or fix the payment to one provider. Fixing it turns off scoring and the cascade for that payment, so use it for specific needs such as a provider-only card programme.
What counts as retry-safe?
A failure that means the provider could not process the payment: the provider or issuer is unavailable, a connector error, or a timeout that the provider has confirmed took no money. A real answer from the bank, such as insufficient funds, a stolen card, fraud, failed authentication or a limit, is never retried elsewhere.
Does cascading cost more?
Scoring weighs cost alongside approval and speed, so when two providers are equally likely to approve, the cheaper one is tried first. A cascade is a fresh attempt on the next provider. How attempts and successful payments are charged is set out on Pricing.
How do you avoid double debits?
Three ways. PediWave never cascades on a real decline. It never cascades on a timeout until the first provider confirms no money moved, and if that provider later reports a success anyway, the extra charge is voided automatically. And every call that moves money carries an idempotency key, so a retried request returns the first result instead of creating a second payment.
Can I test routing before going live?
Yes. In the sandbox, test card 4084 0840 8408 4084 is declined by the first provider and approved by the second, so you can watch a cascade, and 4084 0840 8408 4085 times out and then succeeds on enquiry. You can also call the simulate endpoint with any payment's details to see the decision PediWave would make.
Can I write my own rules or bring my own provider contracts?
Every account is routed by PediWave's default rules from day one. Custom routing rules and connecting providers you already have contracts with are part of Enterprise. Talk to sales to set them up.
Related products
Route smarter from day one.
Every account is routed and protected by these rules from its first test payment.