Guide
Payment orchestration vs reconciliation. Why you need both.
Payment orchestration decides how a payment moves and executes it. Payment reconciliation proves what actually happened. Here is how they differ and how they connect.
Last updated:
Compare the productsThe short answer
Payment orchestration decides how a payment moves and carries it out. Payment reconciliation proves, afterwards, what actually happened. Orchestration chooses a provider, sends the instruction, and tracks each attempt. Reconciliation compares the resulting records with independent evidence until the payment is explained.
Orchestration without reconciliation moves money you cannot prove. Reconciliation without orchestration explains problems after they have already happened. Most businesses that move money for others need both, working from the same record.
How do they compare?
| Orchestration | Reconciliation | |
|---|---|---|
| Question | How should this payment move? | Did it move as intended, and can we prove it? |
| When | Before and during execution | During and after execution, until closure |
| Inputs | The instruction, routing policy, provider capabilities and limits | Your records, provider claims, settlement files, bank statements |
| Output | Attempts with a provider reference and an outcome | Matched payments, and exceptions with an owner |
| Failure it prevents | Wrong route, unsafe retry, duplicate payout | Unproven payouts, silent losses, unexplained balances |
Where does orchestration stop?
Orchestration ends with an outcome from the provider, and that outcome is sometimes uncertain. When a connection drops after an instruction is sent, nobody knows yet whether money moved. A safe orchestrator records this as unknown and looks the payment up. It does not send the instruction again, because a second attempt could pay the recipient twice.
Idempotency keys make retries safer, but they only help if the provider honours them and the orchestrator reuses the same key. See the IETF Idempotency-Key draft for the general pattern.
Where does reconciliation start?
Reconciliation starts with expectations. For each part of a payment it knows which evidence should arrive, from which source, and by when: a provider claim, a line in the settlement file, a bank movement. It then checks that everything arrived and agrees. The payment reconciliation guide walks through the method.
Questions to ask when you evaluate a platform
- What happens after a timeout? Is the outcome recorded as unknown and looked up, or retried?
- Is every status change kept, or does the latest status overwrite the history?
- Which evidence proves a payout: the provider’s API, its settlement file, or your bank statement?
- How does the platform notice a settlement file that never arrived?
- Can a closed payment be reopened by later evidence, such as a reversal, without editing history?
- Can an AI agent move money or change financial records, or only investigate and recommend?
How Flominzo approaches it
Flominzo Payouts orchestrates execution through a common adapter contract, and Flominzo Recon reconciles the result. Both run on one financial core with one intent model, one event history, and one ledger, so the payment is described once.
Sources
Let’s make it specific to you.
Bring your systems, payment flows, and questions. We’ll help define the next step.
Talk to the team