Unsafe failover
Processor A times out. The router sends the payment to Processor B. A captures late. The cardholder is charged twice.
Payment Service Providers
Every processor you add brings its own version of the truth.
Adding providers increases coverage, but it also creates more state, more retries, more settlement paths and more reconciliation work. Orangepill does not replace your processors. It coordinates and governs them, so a payment has one lifecycle no matter how many systems touch it.
The problem
Coverage grows linearly. Operational complexity does not.
A second processor improves approval rates and resilience. It also doubles the status models, webhook formats, settlement files and edge cases your team maintains. By the third or fourth, most engineering time on payments goes into keeping those systems in agreement with each other.
Typical architecture today
A routing layer in front, a reconciliation team behind.
- Merchant request
- Routing rules Pick a processor
- Processors A, B, C Each with its own states
- Merchant balances Updated from webhooks
- Settlement files Matched by hand or script
Routing decides where a payment goes. Little in this design decides what is safe after the payment has gone somewhere and the answer did not come back cleanly.
Where it breaks
The failures sit between processors, not inside them.
Balance drift
A merchant balance is credited from a webhook, then the payment is reversed by a different processor event that arrives out of order.
Settlement mismatch
The processor's settlement file disagrees with what was recorded at authorization, and nobody can say which is right without a manual trace.
Provider-shaped product logic
Every new processor adds conditionals to merchant-facing code, because the lifecycle was modelled on the first provider's API.
Orangepill model
Processors carry payments. The runtime owns what happened to them.
Provider abstraction with memory
Each processor call is an attempt under one payment. The attempt history decides whether another attempt is safe.
Merchant state in a ledger
Merchant balances, fees, reserves and payables are derived from ledger entries, not overwritten by the latest webhook.
Settlement checked, not assumed
Processor reports are compared with the ledger. Reconciliation detects divergence. Resolve governs what happens next.
Capabilities used
What a PSP uses from the runtime.
Multi-Rail Orchestration
Routes across processors under policy and tracks every attempt, so failover is a decision made with the history in view.
Explore Multi-Rail Orchestration →Execution
Owns each payment as one lifecycle, independent of which processor carried it, with idempotent attempts underneath.
Explore Execution →Wallet & Ledger
Keeps merchant balances, fees and settlement obligations as double-entry ledger state rather than a column per processor.
Explore Wallet & Ledger →Resolve
Handles the payments whose processor outcome is unknown or disputed, before anyone retries, settles or refunds.
Explore Resolve →Example workflow
A pay-in through two processors, settled to a merchant.
- Merchant pay-in One payment, one lifecycle
- Attempt via Processor A Declined: final, no effect
- Attempt via Processor B Safe because A is known final
- Merchant ledger Balance, fee and reserve entries
- Settlement verified Processor report vs. ledger
Had Processor A timed out instead of declining, the second attempt would wait until A's outcome was established, or the payment would move to Resolve. The router does not get to guess.
Outcome
More processors without more ways to lose track of a payment.
- Make failover safer by tying it to what earlier attempts actually did.
- Add or remove a processor without rewriting merchant-facing logic.
- Keep merchant balances explainable entry by entry.
- Automate settlement reconciliation and route only real divergence to people.
- Centralise lifecycle authority instead of spreading it across webhook handlers.
Map your current processor architecture with us.
Bring your processor list and one failure you have seen in production. We will show where the runtime would hold the lifecycle and where it would stop an unsafe retry.