State lives with each provider
No single record says where the value is between legs. The answer is assembled by querying everyone.
Cross-Border & Remittance
A remittance is one promise kept across several systems.
The sender pays locally. Value is converted, moved and paid out locally somewhere else. Each leg runs on a different provider with its own states and timing. Orangepill governs the whole movement as one economic intent, then checks the outcome against what the rails actually did.
The problem
Every leg can succeed while the remittance fails.
The pay-in provider reports success. The FX leg reports success. The payout provider times out. Each dashboard is correct about its own step, and none of them can answer the question the sender is asking: did the recipient get the money?
- The pay-in settles, the payout times out, and the funds are neither delivered nor returned.
- An FX quote expires between pay-in confirmation and conversion.
- A payout is rejected after conversion, leaving converted value with nowhere to go.
- Failing over to a second payout provider while the first is still pending risks paying the recipient twice.
- A payout is returned days later, after the remittance was marked complete.
- Settlement reports arrive late and do not match what each leg recorded at the time.
Typical architecture today
Providers in a row, held together by application code.
- Pay-in provider Its own status model
- FX provider Quotes and conversions
- Payout provider Its own status model
- Orders table A status column per remittance
- Batch reconciliation Next day, by file
Glue code owns the sequence
Retries, timeouts and failover are written by hand for each provider pair, and each new corridor repeats the work.
Reconciliation comes after the fact
Mismatches surface in a report hours or days later, long after someone has already retried or refunded.
Orangepill model
Economic Intent ≠ Settlement Rail.
The economic intent of a remittance is simple: deliver a defined value to a recipient at the destination. The rail is only how that intent gets fulfilled. Pay-in method, liquidity source, transfer route and payout provider can all change. The intent does not.
Economic intent
What must be true when the remittance is finished: how much value, in which currency, for which recipient, under which constraints. It is created once and owns the outcome.
Settlement rail
The providers and rails chosen to fulfil the intent. If one fails, another can be tried, but only under rules that know what the earlier attempt did. Changing the rail is a new attempt, not a new remittance.
This separation is what makes adding a corridor or a payout provider a routing decision instead of a product rewrite. The product keeps asking for the same thing; the runtime decides how to deliver it.
Example workflow
One lifecycle from local pay-in to verified delivery.
- Local pay-in Funds collected in the sender currency
- FX / liquidity Conversion against available liquidity
- Transfer Value moved toward the destination
- Local payout Recipient paid on a destination rail
- Verify Ledger and records vs. provider reality
- Resolve if needed Governed disposition when evidence is unclear
Orchestration decides the journey: checks, approvals, which providers to use. Execution moves the value, leg by leg, and records each effect in the ledger. Verification compares that record with what the providers report. Resolve only engages when the two cannot be reconciled from the evidence available.
| Stage | What is recorded | What can go wrong | How it is governed |
|---|---|---|---|
| Local pay-in | Collection attempt, provider reference, ledger entry for funds received | Pending, reversed or late confirmation | Conversion proceeds on established funds, or under an explicit policy exception |
| FX / liquidity | The rate applied and the conversion as its own ledger effect | Quote expiry, insufficient liquidity at the destination | Re-quote or hold under policy; the intent stays open |
| Transfer | Each attempt toward the destination and its provider reference | Timeout with unknown outcome | Attempt stays in an explicit ambiguous state until finality is established |
| Local payout | Payout attempts per provider, linked to the same intent | Rejection, timeout, return after payout | Failover only when the prior attempt can no longer pay; returns recorded against the original intent |
| Verify | Comparison of ledger and execution record with provider reports | Mismatched amount, status or timing | Divergence is flagged, not silently overwritten |
| Resolve | A case with evidence, decision and verification | Finality unclear, records disagree | Investigate → Establish → Decide → Verify; Continue · Wait · Remediate · Escalate |
When a leg goes wrong
The payout times out after the money was converted.
The pay-in is confirmed and the conversion has executed. The payout request to Provider A times out. Sending the same payout through Provider B right away could pay the recipient twice. Refunding the sender could leave them paid and refunded. Neither is safe until someone knows what Provider A did.
- Pay-in confirmed Ledger: funds received
- Converted Ledger: FX effect recorded
- Payout via Provider A Timeout; outcome unknown
- Resolve Is attempt A final? Can it still pay the recipient?
- Paid Verify and close the intent
- Not paid, final New attempt via Provider B, same intent
- Still unknown Wait, or escalate to a person
The remittance never pretends to be complete or failed while the evidence says neither. It stays explicitly unresolved, with every attempt and ledger effect attached, until a safe disposition can be established.
Payout operations
Payouts are where cross-border breaks most visibly.
The last leg is the one the recipient sees, and the one most exposed to local rail behaviour. The same controls apply whether the payout ends a remittance or runs on its own, such as a batch of disbursements.
Routing with memory
Provider selection takes earlier attempts into account. A new route is never chosen as if nothing had happened.
Treasury visibility
Balances per currency and per provider come from the ledger, so you can see what can be paid where before sending.
Idempotent execution
A repeated instruction, a crashed worker or a replayed webhook does not produce a second payout.
What exists for every remittance
A record you can follow from intent to evidence.
- Economic Intent Deliver this value to this recipient
- Execution The governed lifecycle
- Provider Attempts Every try, on every rail
- Ledger Entries Authoritative financial state
- Proof of Record How the outcome was produced
The ledger says where value is. Proof of Record explains how it got there. When a sender asks what happened, support answers from that record instead of three provider portals.
Capabilities used
Four parts of the runtime carry a remittance.
Execution
Holds the remittance as one lifecycle across every leg, so a retry or rail change is another attempt under the same intent rather than a second remittance.
Explore Execution →Multi-Rail Orchestration
Chooses pay-in, FX and payout providers under policy, and only fails over when the previous attempt can no longer create an effect.
Explore Multi-Rail Orchestration →Wallet & Ledger
Records each leg as ledger entries, so in-flight value and per-currency balances are derived rather than estimated.
Explore Wallet & Ledger →Resolve
Takes over when a leg ends in an unknown or mismatched state, and decides what can safely happen next.
Explore Resolve →Outcome
Fewer remittances in an unknown state, and a clear owner for the ones that are.
- Add a corridor, liquidity source or payout provider without rebuilding product logic.
- Fail over between payout providers without risking a duplicate payment.
- Know where in-flight value sits at any point between pay-in and payout.
- Reconcile before remediating, so refunds and retries are based on evidence.
- Replace per-provider glue code with one lifecycle the whole team can read.
Corridor, currency and provider coverage depends on the providers connected for your program. We confirm it during architecture mapping rather than listing it here.
Bring one corridor and we will walk it leg by leg.
Tell us how pay-in, FX and payout are connected today. We will map where the runtime would hold the intent and where your current flow can end up in an unknown state.