Schedule a demo

Pick a time with our team. The scheduler is provided by Calendly and sets its own cookies.

Prefer email? support@coriunder.com

We use your details to arrange your demo. Read our Privacy Policy.

Payouts

One instruction in. The right rail out.

A router that picks the corridor, a cascade that tries the next provider when one fails, pricing that separates what you charge from what it cost, and reconciliation that closes the loop against the provider’s own file. Payouts to bank accounts, wallets, cards and cash pickup.

Payout instruction · API
£2,400.00
GBP → INRBank
Beneficiary on file · A. Mehta
RouterCascade
Provider AFailed
Provider BSent
Cost0.62%Price1.20%
Reconciled to provider file
INR
Bank account
Provider B
Delivered
PHP
GCash wallet
Provider C
Queued
MXN
Debit card
Provider A
Delivered
NGN
Cash pickup
Provider D
Ready
EUR
SEPA Instant
Provider E
Delivered

Payout providers you can route across

Sending money is the easy part

Knowing which rail to use, what it actually cost, and whether it arrived is the part that decides whether a payout operation is profitable or a support queue.

4

Payout types

Per

Corridor configuration

2

Pricing layers

Every

Failure alerted

What it does

From a payout request to money delivered

A payout is a routing decision, a price, an execution and a reconciliation. The platform treats all four as first-class rather than leaving three of them to a spreadsheet.

1A payout request arrivesMerchant: Acme
GBP → INRBank account£2,400.00
2Rules are walked in orderFirst match wins
1MerchantGBP → INR · bankMatched
2Merchantany → PHP · walletSkipped
3ProgrammeEUR → EUR · SEPASkipped
3No match means a clear refusal
USD → VND · wallet
No rule covers this corridor
Refused · no_route

The router

Point a merchant’s payout settings at the router and every request resolves against your rules rather than a fixed provider. Rules are walked merchant first, then programme, in priority order, and the first whose corridor matches the request and whose amount range is satisfied wins. Nothing matches and the request is refused with a clear no-route code rather than being sent somewhere hopeful.

Where the money comes from
1Pick the corridorProvider + route + type
United Kingdom · GBP
→
India · INR
Bank
2The identifier comes with it
Acct + IFSCRequired
IBANNot used
MobileNot used
3So do the limits and dataSet once per corridor
Min
1.00
Max
50,000.00
Cut-off
17:30 local
RequiredSender nameBeneficiary nameAddress

Corridors, not just providers

A corridor is the combination that actually matters: provider, source country and currency, destination country and currency, and payout type. Each one carries what that route genuinely needs. Which recipient identifier is required, whether that is an IBAN, a mobile number, an account number or a name and document. What sender and beneficiary information the destination demands. Minimum and maximum amounts. Picking a route picks all of it at once.

IBAN accounts
1First provider failsBank payout · €3,200.00
P1
Provider 1
Timeout at 14:02:11
Failed
2Next in the resolved orderAutomatic
P2
Provider 2
Retried at 14:02:14
Paid
Merchant notification held while a fallback remained
3Which payouts cascade
Bank accountCash pickup · excludedCard · excluded

Cascade when a corridor fails

A provider going down should not become a failed payout. When a routed bank payout fails, the next eligible provider in the resolved order is tried automatically, and the merchant notification is deliberately held while a fallback remains, so nobody is told a payment failed that is about to succeed. Cash pickup and card payouts are excluded by design, because without a beneficiary bank account there is no tuple to route on.

Payout monitoring
1Retail · what the customer pays
Amount sent1,000.00
Transfer fee · flat + %4.50
FX spread retained0.45%
2Wholesale · what it cost youCaptured at execution
Funded
998.20
Commission
1.20
Rate
105.8400
3Both numbers kept
Margin held
5.10
CostMargin

Two layers of pricing

What the customer pays and what the payout cost you are different numbers, and the platform keeps both. The retail layer holds the amount sent, the transfer fee and the FX spread you retained. The wholesale layer holds what was actually funded to the provider, their commission and the wholesale rate they applied, captured at execution because that is the only moment it is knowable. Fees are configured flat, as a percentage, or both.

Fees and settlement
1Status arrives by webhook09:41
payout.status · PO-58213 · executed200
2A sweep re-checks what is open
PO-58213Bank · INRMatched
PO-58219Wallet · PHPRe-checking
PO-58174Wire · USDReturned
3Vendor settlement fileFrom what executed
vendor_settlement_0925.csv
412 lines · rate + commission per line
CSV

Reconciled against the provider

Every payout is reconciled back against the provider’s own record rather than assumed complete. Status changes arrive by webhook, a sweep re-checks anything still open, and vendor settlement files are produced from what actually executed, with the wholesale rate and commission on each line. When a wire is returned or cancelled it comes back to the payout it belongs to.

Reconciliation
In the box

What comes with payouts

Rule-based router

Merchant rules then programme rules, in priority order.

Corridor configuration

Provider, countries, currencies and payout type as one unit.

Automatic cascade

The next eligible provider is tried when one fails.

Per-corridor requirements

The identifier and KYC each destination actually demands.

Amount limits

Minimum and maximum enforced per corridor.

Flexible fees

Flat, percentage or both, per programme and per merchant.

Wholesale capture

Provider rate and commission recorded at execution.

Margin visibility

Retail against wholesale on every priced payout.

Approval and AML

A checked path before any third-party transfer.

Status webhooks

Provider updates applied as they arrive.

Failure alerting

Failure counts and an all-failed rule on a sweep.

Vendor settlement files

Exports built from what actually executed.

For your integration

The balance layer, as an API.

The web services portal documents the calls behind the wallet: read a total, request an amount, transfer between accounts and between currencies, request a payout, and pull balance rows. The same operations your own product will make, with the request and response for each one.

  • Balance service
  • Transfers
  • Currency conversion
  • Payout requests
  • Balance rows
  • IBAN accounts
  • Prepaid cards
  • Customers
Web services webservices.coriunder.cloud Open the web services portal

Frequently asked questions

  • How does the router choose?

    Rules are resolved merchant first, then programme, in priority order. The first rule whose corridor matches the request and whose amount range is satisfied wins. If nothing matches the request is refused with a no-route code rather than being sent on a guess.

  • What is a corridor exactly?

    The combination of provider, source country and currency, destination country and currency, and payout type. It also carries the recipient identifier that route requires, the sender and beneficiary information the destination demands, and the amount limits. Selecting a route selects all of that together.

  • What happens when a provider is down?

    For routed bank payouts the next eligible provider in the resolved order is attempted automatically. The merchant notification is held while a fallback is still available, so a failure that is about to be retried does not reach them as bad news.

  • Why are cash and card payouts excluded from the cascade?

    Because they carry no beneficiary bank account, so there is nothing to route on. That is a deliberate exclusion rather than a gap.

  • Can we see our margin on a payout?

    Yes. Both layers are stored per payout: what the customer sent, the transfer fee and the FX spread retained, alongside what was funded to the provider, their commission and the wholesale rate. The customer rate is derived from the two, so margin is a report rather than an investigation.

  • How do we know a payout actually arrived?

    Status updates arrive by webhook and a scheduled sweep re-checks anything still open, so a lost notification does not leave a payout stuck as sent. Returned and cancelled payouts come back to the record they belong to.

  • Can we charge different fees per merchant?

    Yes. Payout fees are configured as a flat amount, a percentage, or both, and can differ per programme and per merchant.

Still have a question?
Watch it in the product

Short walkthroughs from the admin

All tutorials

Reviewing payouts

Smart payout routing

Balance requests and the ledger

Send to more places, and know what it cost.

Tell us the corridors you need and we will map them to providers with you.

Provider and corridor availability depends on your licence and destinations. Talk to our team.