Paying sellers
Automatic payouts and the reserve for Lite merchants, and paying many sellers at once for Relay.
How a seller gets their money depends on the connection's mode. A direct merchant runs their own
account and withdraws from it themselves; nothing on this page applies to them. A lite merchant
has no dashboard to withdraw from, so Wajub pays them. A relay marketplace collects everything and
pays its sellers from its own balance.
Lite: Wajub pays the merchant
A Lite merchant is paid on the cadence you set on the connection. Each payout is a sweep: what is available on their balance, less the reserve, less room for the payout's own fee.
payout_schedule | What happens |
|---|---|
manual (default) | Nothing, until you ask with POST /accounts/{id}/payouts |
daily | Paid once a day |
weekly | Paid once a week |
monthly | Paid once a month |
Set it with POST /accounts or PUT /accounts/{id} at any time. Unlike capabilities and pricing it
changes outright: when a merchant gets their own money takes nothing from them. It only exists on a
lite account — sending it for a direct or relay account is refused with 400, since Wajub
pays nobody there.
curl -X POST https://api.wajub.com/accounts/acc_7Yh2MpL4tRb3nP8sZcXv/payouts \
-H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…"| You get | When |
|---|---|
200 and the transfer | The payout was sent |
409 There is nothing to pay out yet. | The sweep is below payout_min_amount |
422 with a reason | No destination declared, connection not active, or a payout limit reached |
A connection is swept at most once a day, whoever asks. A second call the same day returns the payout that already went. The amount is never yours to choose: it is what the merchant can be paid.
Why the payout is a little under the balance
A payout's fee is held alongside its amount, so sweeping the entire balance would leave the payout short of its own fee. The sweep sends the largest amount whose fee still fits. A merchant paid into another Wajub account pays no fee, and is swept in full. Only the balance in the merchant's own currency is swept; a balance they hold in another currency waits for them to withdraw it.
Every payout goes to the destination the merchant declared in their portal, and passes the same checks as any other transfer — including the cooling-off period on a destination that was just declared or changed.
The reserve
A Lite merchant is paid without asking, so money can leave while the buyer can still be refunded. The reserve keeps a slice of every sale back until that window closes: 10% for 30 days by default.
| Then | What happens to the reserve |
|---|---|
| A payout runs | It sends everything except what is held |
| A sale is refunded | The refund eats into the reserve first |
| The window closes | That slice is released and joins the next payout |
The reserve is not a charge and not a separate balance. The money stays the merchant's; the reserve only says how much of it may not leave yet. The rate and duration are set by Wajub for a connection, not by the platform.
When a merchant goes negative
If a refund lands after a merchant has been paid and the reserve is not enough, their balance goes below zero. You cover it. The shortfall moves from your balance to the merchant's, the same moment the refund is processed, and is recorded against that refund.
This is the other side of Lite
Lite lets you recruit merchants without asking them to run a Wajub account. The merchants are yours, and so is what they owe after a refund. A Direct merchant, running their own account, carries their own negative balance instead.
When your commission cannot be taken at once
A direct merchant can collect on their own provider contracts. Those sales never touch a Wajub
balance, so there is nothing to take your commission out of when they happen. It is owed instead:
| Then | What happens |
|---|---|
| The sale happens | The commission is recorded as owed, and account.commission_receivable_recorded is sent |
| The sale is refunded | What is owed is reduced by the connection's commission_refund_policy, as a commission taken would be |
| The merchant's Wajub balance can cover it | It is collected in full, and account.commission_receivable_collected is sent |
Collection never pushes the merchant below zero: an unpaid commission waits for money to arrive.
GET /accounts/{id}/commission-receivables lists what a connection owes you and totals what is still
outstanding.
Relay: paying many sellers at once
A Relay marketplace collects every payment and pays its sellers from its own balance. Each seller is a beneficiary, and a payout run is one call.
curl -X POST https://api.wajub.com/transfers/batch \
-H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
-H "Idempotency-Key: payout-run-2026-09-30" \
-H "Content-Type: application/json" \
-d '{
"transfers": [
{ "beneficiary": "ben_01JX…", "amount": 125000, "reference": "seller-42" },
{ "beneficiary": "ben_01JY…", "amount": 48000, "reference": "seller-43" }
]
}'| Rule | Why |
|---|---|
| Up to 500 lines per call | Beyond that, split the run |
Idempotency-Key is required | Retrying a run after a timeout sends only the lines that did not land |
Each reference is unique in the batch | Each line's own key is built from it |
| Lines succeed or fail on their own | One seller without a verified destination does not stop the others |
The answer lists every line with accepted or rejected and the reason. Each transfer keeps your
reference and the run's batch_reference, which is what ties it back to your own records.
Sellers are checked before their first payout
Wajub pays sellers you recruited, so on a Relay account each new beneficiary's wallet is matched against the name its operator has on file before it can be paid. Declare the seller's full name as it appears on their wallet: at least two words have to match.
verification on the beneficiary | What it means |
|---|---|
verified | The names match; the seller can be paid |
name_mismatch | The operator knows this wallet under another name; payouts to it are refused |
lookup_unavailable | The operator could not be asked; try again later |
verified is true or false on every beneficiary you read. Retry a check with
POST /beneficiaries/{id}/verify — after the operator was down, or once you have corrected the name.
A line in a batch that pays an unverified seller is rejected on its own, and the rest of the batch goes
through.
Only Relay, and adjustable
An account that does not run Relay keeps creating beneficiaries that are payable at once, as it always has. Wajub can relax the check for a Relay marketplace it has vetted, or require it from any other account — ask if either applies to you.
When a paid seller owes money back
A sale is refunded after you paid the seller for it. The refund comes out of your balance, and nobody can pull money back out of a Mobile Money wallet — so the seller now owes it. Only you know which seller the order belonged to, so you declare it:
curl -X POST https://api.wajub.com/beneficiaries/ben_01JX…/receivables \
-H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
-H "Content-Type: application/json" \
-d '{ "amount": 12500, "reference": "order-9981-refund" }'Declaring the same reference again returns the first debt. Wajub records it and sends
beneficiary.receivable_recorded. What happens next depends on your account:
| Netting | What happens |
|---|---|
| Off (default) | Nothing else. You recover it however you like, then mark it with POST /beneficiaries/{id}/receivables/{receivable}/settle |
| On | Your next payout run to that seller is reduced by what they owe, and beneficiary.receivable_recovered is sent |
With netting on, each batch line reports recovered. A line whose payout is smaller than the debt
sends nothing, answers status: recovered, and the rest stays owed. Recovering only happens in
POST /transfers/batch; a single POST /transfers always sends what you asked. Ask Wajub to turn
netting on for your account.
A failed line owes the debt again
If a line's payout is refused, whatever it would have recovered goes back on the debt. Retrying the run never recovers twice.
Statements
GET /beneficiaries/{id}/statement?from=2026-09-01&to=2026-09-30 returns everything paid to one
seller over a period, up to a year. Totals are split into paid, in_progress and failed: a payout
that failed is on the statement, but never counted as paid.
Payout velocity
Every account has an hourly ceiling on payouts, built for a merchant paying suppliers — not for a marketplace paying two hundred sellers. Contact Wajub to have yours raised before your first run. It is set by Wajub for your account and cannot be raised through the API.