# Paying your sellers is two problems, not one

> How African marketplaces pay sellers: wallet payouts where the rail is live (Tanzania today), bank settlement everywhere else, and the ledger in between.

Published 2026-10-11 by the Ultraner team. Topic: build. Tags: marketplaces, payouts, settlement, split-payouts.
Canonical: https://ultraner.com/blog/how-marketplaces-pay-sellers-in-africa

Every marketplace founder in Africa eventually writes the same sentence in a planning doc: "Then we pay the sellers." It sits there as one line. It is at least two problems, and treating it as one is how marketplaces end up with a finance person reconciling payouts in a spreadsheet at midnight.

The two problems are these. First, getting money to a seller's mobile money wallet, which is what most small sellers want. Second, getting your own accumulated balance to a bank account, which is what your company needs. They sound like the same act. They run on different rails, with different reach, different costs and different failure modes.

## The word "payout" hides the split

At Ultraner we keep the vocabulary strict, because the loose version caused real confusion on our own pages:

- **Disbursement** means paying money from your balance into somebody else's mobile money wallet. It runs through a gateway's payout rail, and each rail is verified and switched on one market at a time. **Today that is live in Tanzania.** The other markets are being brought up.
- **Settlement** means moving your own balance to your own bank account by wire. That works in every country in the world, whichever African markets you collected in.

So "can we pay sellers in Kenya?" has an honest answer with two halves. You can collect from Kenyan buyers today. You can settle the proceeds to your bank wherever it is. You cannot yet push money into a Kenyan seller's M-Pesa wallet through Ultraner. The [payouts page](/payouts) keeps the current state of each.

## Shape one: Tanzania, wallet to wallet

If your sellers are in Tanzania, the flow you probably imagined works as imagined.

1. A buyer pays TZS 120,000 for a phone case order through M-Pesa (Vodacom), Mixx by Yas, Airtel Money, Halopesa, TTCL T-Pesa or AzamPesa.
2. The money lands in your balance.
3. You take your commission, say 10%, TZS 12,000.
4. You disburse TZS 108,000 to the seller's own wallet, on whichever of those networks they use.

Disbursement carries a flat 3% Ultraner fee on top of whatever the underlying gateway charges (MalipoPay charges TZS 500 per mobile money payout, for example). The fee comes out of your balance with the payout and is refunded if the payout fails. Decide whether that cost comes out of the seller's share or your commission, and write it in the seller terms before the first payout, not after.

For a weekly payout run, do not send two hundred separate calls from a cron job. `POST /v1/payroll/batches` takes up to 500 items, and `POST /v1/payroll/batches/{id}/submit` is the single call that moves the money. Batching also gives your finance team one object to approve. The [Tanzania payments page](/payments/tanzania) lists the networks and number format.

## Shape two: everywhere else, settle then pay onward

For sellers outside Tanzania today, the money takes a longer road:

1. Buyers in Kenya, Uganda, Rwanda or any of the other live markets pay by mobile money, card or PayPal.
2. Your balance accumulates.
3. You settle to your company's bank account. 3% into a US bank account, 4% anywhere else, with the FX spread shown separately if your bank account is in another currency.
4. Your bank, or your local payment partner in that country, pays the sellers.

This is less elegant and it is what most pan-African marketplaces actually run. The thing to get right is that your marketplace ledger, not your bank statement, is the source of truth for what each seller is owed. The bank transfer is just how a batch of those obligations gets discharged.

## Shape three: let the platform do the split

If you want sellers to have their own balances rather than living as rows in your database, Ultraner's [split payouts](/capabilities/split-payouts) (we call the product Streamline) lets you onboard your own sellers, take your cut automatically at payment time, and pay out the rest. Onboarding is self-served.

One caveat to understand before you choose this: refunding a split payment reverses your platform fee as well. If the seller has already withdrawn their share, their balance can go below zero and has to be topped up before any further payout. That is the correct accounting, and it means your seller agreement should say what happens when a refund lands after a withdrawal.

## The ledger you need either way

Whichever shape you run, you need four numbers per seller per period, and they should come from your own records:

- **Gross sales** collected on their listings.
- **Your commission.**
- **Fees** (collection fees, payout fees) and who bears each.
- **Refunds and chargebacks** clawed back.

What the seller is owed is the first minus the other three. Store each payment's Ultraner `transaction_id` against the order, and drive your seller ledger from `payment.success` and `refund.success` webhooks, not from what the buyer's browser told you.

Two habits keep this clean:

**Hold before you pay.** A seller paid the minute the buyer pays has nothing at stake if the item never arrives. Most marketplaces hold funds until delivery is confirmed or a return window closes. Ultraner's [escrow](/capabilities/escrow) does this per transaction if you want the hold enforced by the payment itself rather than by your scheduler.

**Use an idempotency key on every payout.** If a payout request times out you genuinely cannot tell whether the money moved. Ultraner requires an `Idempotency-Key` on every API call that moves money out, the same pattern the IETF has been standardising for HTTP APIs [3]. Retry with the same key and you get the original response, not a second payout. Use something deterministic like `seller-4411-2026-W41`, never a random value generated per attempt.

## Why sellers care which shape you pick

The GSMA's industry reports put most of the world's mobile money activity in Sub-Saharan Africa [1], and the World Bank's Findex shows that for many adults in the region a mobile money account is the financial account, not an add-on to a bank [2]. For a small seller, a payout that lands on their phone the same day is worth more than a slightly bigger one that lands in a bank account they visit monthly.

That is a reason to push hard for wallet payouts where they exist, and to be straight with sellers where they do not yet. "Weekly bank transfer, every Friday, with a statement" is a promise a seller can plan around. "We will pay you soon" is not.

## A decision table

| Your sellers are in | Buyer pays with | Seller receives by | Use |
|---|---|---|---|
| Tanzania | Any method | Their own mobile wallet | Disbursement or payroll batch |
| Any other live market | Any method | Bank transfer from you | Settlement, then your bank |
| Mixed | Any method | Their own platform balance | Split payouts (Streamline) |

Whatever you pick, write the payout schedule into the seller agreement on day one, put the per-seller statement in their dashboard, and price the payout fee into your commission rather than surprising anyone with it. Check the current numbers on [pricing](/pricing) before you commit to a commission rate.

## Sources

[1] State of the Industry Report on Mobile Money, GSMA. https://www.gsma.com/sotir/
[2] The Global Findex Database 2025, World Bank. https://www.worldbank.org/en/publication/globalfindex
[3] The Idempotency-Key HTTP Header Field (Internet-Draft), IETF. https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/