Paying sellers

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.

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.xxxxxxxxxxxxxxxx…"

A connection is swept at most once a day, whoever asks. A second call the same day sends nothing and returns that day's sweep, whatever its status: check transfer.status, it can be failed, and the next sweep is the next day's. Only the sweeps count: a payout you sent yourself with X-Sync is never returned here. The amount is never yours to choose: it is what the merchant can be paid.

Every payout goes to the destination the merchant declared in their portal, and passes the same checks as any other transfer, the cooling-off period on a destination that was just declared or changed included.

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.

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 or a lost dispute 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 or the loss is processed, and is recorded against it, up to the amount it took.

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:

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.xxxxxxxxxxxxxxxx…" \
  -H "Idempotency-Key: payout-run-2026-09-30" \
  -H "Content-Type: application/json" \
  -d '{
    "transfers": [
      { "beneficiary": "ben_LRQqYvlhrgUOE225KMKU", "amount": 125000, "reference": "seller-42" },
      { "beneficiary": "ben_7Hn2Qw9Xk4Lp3Rv8Tb6MzD", "amount": 48000, "reference": "seller-43" }
    ]
  }'

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 exactly as it appears on their wallet.

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. Here the call is a gate, not a lookup: it answers 422 unless the result is verified, and it never returns the name the operator holds. A line in a batch that pays an unverified seller is rejected on its own, and the rest of the batch goes through.

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_LRQqYvlhrgUOE225KMKU/receivables \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -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:

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.

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.