Payout orchestration
Payout orchestration across providers. Integrate once. Route with evidence.
Flominzo Payouts is payout orchestration for fintechs, PSPs, and platforms: one model for every provider, rule-based routing, and every payout reconciled.
Last updated:
Discuss your payout routesAgentic payments
Payments, built for agents.
One chapter of Kwame’s day, run through a chat. The same limits, approvals and evidence govern it as every other payment.
Payouts, routed live
PayoutsonlineWhatsApp- To
- Ama Mensah · MTN, Ghana
- Amount
- GH₵ 3,120.00
- Route
- Partner B
Why Partner B? We usually use Partner A for Ghana.
Partner A’s MTN success rate fell to 71% in the last hour, below your 95% policy, so routing chose Partner B.
Partner B then timed out, so the outcome was unknown. Nothing was retried: I asked Partner B for the status instead.
- Status checkPaid 14:02
- Duplicate payoutNone
- Partner fileAwaited
Kwame’s instruction reaches the payout network once. Flominzo routes it through the partners and policies agreed for the business, keeps every attempt against the original instruction, and treats an unknown result as something to check, not something to retry blindly.
Routing follows the rules you configure; the assistant explains decisions and never moves money. Chat channels are agreed for your deployment.
Early-bird offer
Flominzo AgentPay
$3,999 setup + $999 a month
Early-bird for the first 20 customers: integration with your providers and bank or settlement files by the Flominzo team, every payment reconciled to closure, and the operations console. Month to month, no minimum term.
On this page 12 sections
What Flominzo Payouts is
Flominzo Payouts is a payout orchestration and routing layer. It lets fintechs, payment service providers, marketplaces, and payout platforms connect banks, mobile-money operators, aggregators, and cash networks through one execution model, instead of integrating and operating each provider separately.
Payouts separates the instruction to move money from the provider-specific API that carries it out. Your systems send one canonical payout; rail adapters translate it for each provider and translate every response back into one vocabulary of statuses and result classes.
Payout orchestration, routing and failover
Payout orchestration means your systems send one payout instruction, and a routing layer decides which provider carries it out, executes it through that provider’s adapter, and keeps one record of the result, whichever provider was used. It is what lets a platform add a second or third payout provider for resilience, cost or coverage without rebuilding its payout flow each time.
- One instructionYour system sends a canonical payout with its idempotency key.
- Eligible routesAdapters declare which providers can pay this corridor and method.
- Routing policyYour rules choose a route by balance, cost, FX, success rate and health.
- Execute and classifyThe adapter sends it and classifies the result.
- Fail over or resolveA definite rejection can fail over. An unknown outcome is looked up, never re-routed.
Multi-provider payout routing works because every provider is behind the same canonical model: one beneficiary format, one status vocabulary and one event history. Routing then becomes a policy you configure and approve, rather than code you rewrite for each provider.
Failover is only safe after a definite rejection. If a provider times out or gives no usable answer, the payout may already have been paid, so sending it through a second provider could pay the recipient twice. Flominzo Payouts resolves that outcome with the first provider by status lookup and evidence before any other route is considered. Provider health checks mark degraded or unavailable routes, so new payouts can be routed elsewhere while payouts already in flight are resolved where they are.
How a payout is executed
- Intent: The payout becomes a payment intent with a canonical beneficiary: account, wallet, or pickup details, plus amount, currency, and purpose.
- Route: The routing policy chooses an eligible provider for the corridor and method, using the rules agreed for your environment.
- Execute through the adapter: The rail adapter sends the instruction with an idempotency key and classifies the result as
SUCCESS,RETRYABLE,NON_RETRYABLE, orUNKNOWN_OUTCOME. - Record: Every attempt, callback, and status change is appended to the event history, and the ledger records the financial effect.
- Reconcile: Provider claims are compared with the provider’s settlement file and your bank statement.
- Close: The payout closes when the evidence agrees. A reversal or a late record reopens it.
Every Flominzo product runs through the same lifecycle: intent, plan and execution, rail adapters, events and ledger, reconciliation, and financial closure. Explore the architecture.
Routing rules you control
| Rule | What it considers |
|---|---|
| Balance-aware | The prefunded balance available with each provider before it is chosen. |
| Cost-aware | Provider fees for the corridor, method, and amount. |
| FX-aware | The rate and currency path each provider offers. |
| Success-rate-aware | Recent acceptance and completion by provider and method. |
| Health-aware | Provider health checks, and degraded or unavailable routes. |
| Failover | An alternative eligible route after a provider definitively rejects the instruction. |
Routing policy, eligible providers, and failover rules are configured and approved for your deployment. Failover follows a definite rejection, never an unknown outcome.
Unknown outcomes are never retried blindly
A timeout does not mean the payout failed. Flominzo Payouts records it as UNKNOWN_OUTCOME and resolves it by a status lookup, settlement evidence, or a recorded human decision - never by sending the instruction again or routing it to a second provider. That is how a network timeout avoids becoming a duplicate payout.
Capabilities
- One payout interface over every connected provider. The execution contract is supplied during integration; the public REST API documents the read side.
- A canonical beneficiary model across banks, wallets, and cash networks.
- Country, corridor, and method discovery from each adapter’s capability declaration.
- Idempotency on every instruction.
- Normalised statuses and webhooks, with signatures verified before parsing.
- Provider health monitoring.
- Settlement integration: prefunded or postpaid models, cut-offs, and settlement accounts per provider.
- Reconciliation built in through Flominzo Recon.
100% reconciliation built in
Every payment ends either matched against independent evidence (provider, settlement file, bank statement) or as an open exception with an owner and a reason - none is silently assumed paid.
For payouts, every provider claim is checked against the provider’s settlement file and the cash movement on your bank statement. A payout the API reports as paid but the daily file leaves out becomes an API_CSV_DISAGREEMENT exception with an owner, not a silent gap in a spreadsheet.
Who Payouts is for
- Fintechs and wallets paying out to bank accounts and mobile money.
- PSPs and payout platforms operating several providers for the same corridor.
- Marketplaces and gig platforms paying sellers and contractors, with Flominzo Business.
- Remittance companies separating the customer journey in Flominzo Send from execution.
Markets
Rails, statement formats, and regulation differ in each market. Flominzo is connected through rail adapters to the providers you use; markets, rails, and activation are agreed for your deployment.
Questions
Is there a public payout API or sandbox?
No. The execution contract, credentials, and environment are supplied during integration. The public REST API documents read access to payment state, evidence, and exceptions.
Which providers can we route through?
The providers you use, connected through rail adapters that implement the Rail Adapter Contract. Providers, corridors, methods, and activation are agreed for your deployment.
Can we keep our existing provider integrations?
Yes. You can start by reconciling the payouts your current integrations already make, then move routes onto Flominzo Payouts one provider at a time.
What happens when a provider retires an API?
The change stays inside that provider’s adapter. Every response case is tested before cutover, and the rest of your payout flow does not change. Read the use case.
Related guides
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