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 day with Kwame: money home to his mum, the old way and then in one sentence, a bill for her, his company’s invoices, and the close. The same limits, approvals and evidence govern every step.
- You send
- £200.00
- Rate, locked 10 min
- 1 GBP = 15.60 GHS
- Fee
- £1.50
- Mum receives
- GH₵ 3,120.00
- Pay by bankBarclays
- CardVisa •••• 4242
- Paid inDone
- ConvertedDone
- Mobile moneyPaid
Kwame picks who gets the money and how it arrives, sees the locked rate and the full price, pays, and follows the payment through collection, FX, payout and settlement. Every step lands in one payment record.
Illustrative. Corridors, payout methods, rates and chat channels (WhatsApp included) are agreed for your deployment.
Send Mum £200 for school fees.
Mobile money, like last time.
- To
- Ama Mensah · MTN, Ghana
- Rate, locked 10 min
- 1 GBP = 15.60 GHS
- Fee
- £1.50
- Mum receives
- GH₵ 3,120.00
- Pay by bankBarclays
- CardVisa •••• 4242
- Paid inDone
- ConvertedDone
- Mobile moneyPaid
Did it arrive?
Yes. Mum was paid at 14:02, and the partner’s records confirm it.
The same payment, in one sentence. AgentPay works out who, how and how much, asks only what it can’t know, locks the rate, and takes payment in the chat. Underneath, the same core, limits and approvals run it, and “did it arrive?” is answered from evidence.
Illustrative conversation. Chat channels, WhatsApp included, are agreed for your deployment.
14:02 · Behind the chat, the payout is routed and checked.
Payout infrastructurePayouts, routed live
Explore Flominzo Payouts- 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.
Illustrative. Routing follows the rules you configure; the assistant explains decisions and never moves money. Chat channels are agreed for your deployment.
Also put GH₵ 150 on Mum’s electricity meter.
- Service
- Electricity · prepaid
- Meter
- 0412 •••• 7719
- Account name
- A. Mensah
- You pay
- £9.62 (GH₵ 150.00)
Confirm
Paid. The token is 4829 1177 0356 2210 5841, and I’ve sent it to Mum.
- Biller responsePaid
- TokenDelivered
- Biller settlementMatched
Flominzo checks the meter with the biller before any money moves, pays through the connected biller or aggregator, and tracks the service and the settlement separately, so a paid response never hides a missing token.
Illustrative. Validation and receipts depend on each connected biller; chat channels are agreed for your deployment.
16:30 · Back at work: the company’s invoices.
Business paymentsInvoices, on a mandate
Explore Flominzo BusinessPay all approved invoices due tomorrow, but nothing above £10,000 without asking me.
- Sharma TextilesINV-2231 · ₹85,000.00Approved by Sarah
- Accra WeaversINV-118 · GH₵ 48,000.00Approved
- Kumasi LogisticsINV-77 · £12,400.00Over £10,000
- ₹85,000 at 118.00
- £720.34
- GH₵ 48,000 at 15.60
- £3,076.92
- Total
- £3,797.26
Approve. Hold Kumasi until I’ve checked the delivery.
- Sharma TextilesPaid
- Accra WeaversPaid
- Kumasi LogisticsHeld
Kwame sets the rule once; the agent applies it. Approved invoices are paid to the right supplier, in their currency, at a locked rate, and anything outside the mandate waits for him. Each payment keeps its own execution and history.
Illustrative. Mandates, approval rules, payout partners and chat channels are agreed for your business.
Next morning · The books close, with proof.
Agentic operationsRecon Agent
See how reconciliation works- Payment
- TX-20418
- Provider API
- Paid 14:02
- Partner file, 23 Sep
- Not listed
The provider says PAID, but the 23 September partner file doesn’t list Mum’s payout.
That file closes at 14:00 and the payout landed at 14:02. It’s in the 24 September file: same reference, same amount.
- Action
- Match to the 24 September file
- Evidence
- 2 records attached
Approve.
Recorded your decision. TX-20418 is reconciled, with the evidence and your approval in its history.
An agent that works your exception queue. It correlates evidence across providers, partner files and bank statements, explains what it found in plain language, and recommends a resolution. You approve what happens next.
The Recon Agent never moves money and never changes a state. A person approves every resolution. Chat channels are agreed for your deployment.
Agentic payments
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.
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.
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