How to pay out sellers and service providers on Fynex
How to pay out sellers and service providers from one platform: add each as a payee, register a bank account, fund their wallet, send and track payouts.
To pay out sellers and service providers on Fynex, register each one as a payee, add their bank account as a payout method, and let your split rule credit their share to their wallet. Then send a payout from that wallet. Each payout names an explicit destination, carries an idempotency key, and waits for approval before money moves.
This guide is for marketplace and platform teams wiring payouts: who gets paid, from which balance, and what happens when a payout fails. It is the implementation side. For the decisions behind it (payout schedules, rails and cross-border sellers), read how to pay out marketplace sellers. If you are still choosing a provider, see the best payout platforms for marketplaces.
How to pay out sellers on Fynex: the steps
Eight steps take a new seller from sign-up to a completed payout. Each works in the dashboard or over the payouts API.
- Create a Fynex account. The setup dock walks you through a first payee, a commission rule, an invoice and a test payment. You can explore in sandbox before verification. The getting-started guide covers every screen.
- Add the seller or service provider as a payee. Business name, email, role, tax ID, phone and address. Over the API,
POST /payments-api/v1/payees. A wallet is created for them automatically. - Register their bank account. In the payee form, add the recipient’s bank country, account number and routing number or BIC. Over the API,
POST /payments-api/v1/payees/{payee_id}/payout-methods. Payout methods are bank accounts. - Fund their wallet. For sellers, your split rule credits each share when a payment settles. For a service provider paid outside a split, fund the wallet from your main balance.
- Let the hold mature. Split shares become payable after a set number of business days. Three by default.
- Create the payout.
POST /payments-api/v1/payees/{payee_id}/payoutswithpayoutMethodId,amount,descriptionandidempotencyKey. The payout waits for your approval before money moves. - Track it to completion. Poll
GET /payments-api/v1/payouts/{id}until the status iscompleted,failedorcancelled. - Reconcile it. Every payout is a wallet entry tied back to the payment that funded it, and it lands in QuickBooks or Xero with that link intact.
Starting from nothing? POST /payments-api/v1/payees/setup creates the payee, its payout method and a cashout wallet in one call.
What do you need before the first payout?
Three records have to exist before any money can leave: a payee, a payout method on that payee, and a wallet with enough available balance. Each has one source.
| You need | Where it comes from | Docs |
|---|---|---|
| Payee | Dashboard payee form, CRM import at sign-up, or POST /payments-api/v1/payees | payees |
| Payout method | The payee’s bank details: country, account number, routing number or BIC, account name | payout-methods |
| Wallet | Created with the payee; credited by splits or funded from your main balance | wallets |
| Available balance | The wallet’s balance less any share still under hold | splits |
| Description | Your remittance text, 1 to 140 characters, shown on the recipient’s bank statement | payouts |
Collect tax ID, legal name and address once, at onboarding. Clean payee data now saves a remediation project at filing time. See payee data remediation before filing deadlines.
Paying sellers vs paying service providers: what changes?
The payout is the same; the funding differs. Sellers are funded by the split. Service providers are often paid for work, not for a share of one sale.
- Sellers. A customer pays, the split rule credits the seller’s share to their wallet, and the payout draws on that wallet. The seller’s balance is exactly what the split owes them. Refunds are planned against the same shares.
- Service providers and contractors. A cleaner, a driver, a freelance designer. Their pay may come from several bookings, a fixed fee or an invoice. Fund the wallet from your main balance, then pay out. The payout’s description tells them what it covers, for example “Invoice 2026-091 September commission”.
Both are payees, so both sit in one list with one payout history. That is the point of running payouts through one layer: you run the business, not a second payout tool per party. Fynex applies agentic finance to the routine: it prepares the run, shows its reasoning, and you approve.
How does Fynex choose the payout rail?
You give Fynex the destination; Fynex picks the rail. The payout method’s bank country, currency and account format decide the route, so a client never selects a rail by hand.
- US accounts (routing number plus account number) are paid over ACH.
- EUR accounts (IBAN) are paid over SEPA.
- UK accounts (sort code plus eight-digit account number) are paid over Faster Payments.
A payout always names its payoutMethodId. There is no fallback to a default destination, so a payout can never silently re-route. For the trade-offs between rails, see ACH vs wire and how payout schedules work.
What happens when a payout fails?
A failed payout returns the money to the payee’s wallet, and the payout record says why. Nothing is lost between states.
| Status | What it means |
|---|---|
pending | Created in Fynex, queued |
processing | Submitted to the payment network |
completed | Left the wallet and reached the bank account |
failed | Rejected by the network; balance returned to the wallet |
cancelled | Stopped before processing |
On a failure, branch on failureCode and show the seller failureMessage, which is written to be shown as-is. If the wallet cannot cover the amount, the request returns 409 insufficient balance. Top up and retry with the same idempotencyKey: a replay never creates a second payout. A payee you archive is never paid, so an offboarded seller cannot receive money by accident. The payout failure reasons reference covers the bank-side causes.
How do you make payouts safe to retry?
Send an idempotencyKey with every payout, and a retry can never pay twice. Networks time out; a payout API has to make the second attempt harmless.
- Same key, same body: Fynex returns the original payout. No second payout is created, and no error is raised.
- Same key, different description: the request is refused with
409, so a changed payout is never mistaken for a replay. - No key: Fynex generates one, but then your retry is a new payout. Generate the key yourself and store it with the obligation it pays.
- Key in two places: the body’s
idempotencyKeywins over theIdempotency-Keyheader.
Keep one key per obligation, for example per seller per payout run. Then a crashed job can simply run again. See idempotency and retries under the payouts tag.
Where to go next
- Payouts on Fynex: the feature, across every vertical
- Fynex for marketplaces: commission, payouts and reconciliation for multi-seller platforms
- API reference: payouts, payout methods and payees
- Marketplace seller balances: the wallet each payout draws on
- Pricing: $20 a month plus 0.05% per transaction