Payouts, tracked to the last status.
Bank payouts on local and international rails, card and wallet payouts where supported, batch and API initiation, managed beneficiaries and a status model that tells you what actually happened to each payment.
Paying out is where silence is expensive
An outbound payment that disappears into a rail with no status is a support ticket, a reconciliation break and a trust problem. Payouts are built around the lifecycle: validated beneficiaries, explicit statuses from submitted through to settled or returned, and reconciliation back to the funding source.
From request to reconciled
Manage beneficiaries
Beneficiary details are stored, validated against the destination rail's format rules, and reused, so the same mistake is not re-keyed every cycle.
Initiate
Single payouts through the API or the dashboard, or batches for payroll-style and marketplace-style runs.
Screen
Payouts pass compliance screening before submission, in line with the obligations that apply to the partner and the rail.
Submit
The payout is submitted on the appropriate rail for the destination, currency and amount.
Track to the end
Status moves through submitted, in progress, settled, returned or failed, with the reason attached on anything that does not complete.
What payouts covers
Bank payouts
Credit transfers to a beneficiary bank account on local or international rails.
Card payouts
Push-to-card payouts where the scheme programme and the route support them. Availability is confirmed per merchant.
Wallet payouts
Payouts to supported wallet destinations where the partner and market make them available.
Local payout rails
Domestic rails in supported markets, which are usually cheaper and faster than an international transfer.
International payouts
Cross-border payouts where a local rail is not available for the destination.
Batch payouts
Submit many payouts in one operation, with per-item status rather than a single opaque result.
API payouts
Programmatic initiation from your own system, with idempotency so a retried request cannot double-pay.
Merchant withdrawals
Move available balance to your own nominated account on your own schedule.
Beneficiary management
Stored, validated beneficiary records with format checks for the destination rail.
Payout status tracking
Explicit lifecycle states with failure and return reasons, delivered by webhook.
Reconciliation
Every payout reconciles against its funding source and appears in statements and exports.
Why teams choose it
- No silent failures. Every payout ends in an explicit state, with a reason when it does not complete.
- Fewer rejected payments. Beneficiary validation catches format errors before the rail rejects them.
- Safe automation. Idempotent API initiation means a retry cannot create a duplicate payment.
How you connect
- API: single and batch payout initiation with idempotency keys.
- Dashboard: manual payouts and batch upload for teams without an integration.
- Webhooks: status changes including returns and failures.
What you can accept
- Bank credit transfers, local and international
- Push-to-card where supported
- Wallet payouts where supported
Availability depends on merchant category, jurisdiction, underwriting and the applicable payment or acquiring partner.
How it is controlled
- Payouts are screened before submission in line with applicable obligations.
- Beneficiary changes and payout approvals are recorded and attributable.
- Payout rails are operated by licensed partners under their own authorisations.
Flowa Pay provides the payment technology and orchestration layer. Acquiring, scheme settlement and regulated payment services are provided by licensed acquiring and payment partners under their own authorisations.
Common questions
No, not universally, and we will not claim otherwise. Speed depends on the rail, the destination and the cut-off times in play. Some local rails settle in seconds; international transfers take longer.
Where the scheme programme and the route support push-to-card for your category and market. It is confirmed per merchant rather than assumed.
It is reported as returned with the reason from the rail, and reconciled back so the funds are visible rather than unexplained.
Yes. The API uses idempotency keys, so a retried request after a timeout cannot create a second payment.
Ready to put payouts to work?
Talk to our team about your corridors, your volumes and the routes that fit your business.