Fees & pricing
What Wajub charges on a collection and on a payout, and where to read it back.
Wajub charges a percentage, on both legs, and only on an operation that succeeded. A payment that fails costs nothing, and so does a payout that never reached its recipient.
There is no fixed component on a Wajub fee and no minimum. The rate comes from your plan, and the
whole thing is a straight multiplication, rounded to the precision of the currency. In XAF, whose
precision is zero, a fee is a whole number of francs.
What a collection costs
The rate is read from your plan, per channel. These are the rates configured today.
| Plan | MTN and Orange Cameroon | Every other channel |
|---|---|---|
| Pay as you go | 2.0 % | 2.0 % |
| Growth | 1.7 % | 2.0 % |
| Scale | 1.5 % | 2.0 % |
| Enterprise | 1.2 % | 2.0 % |
The second column is not a rounding of the first. The plan rate applies to cm.mtn and cm.orange
only; every other channel, Express Union and every country outside Cameroon included, is charged the
default 2 % whatever your plan. Ask before you model margins on a
corridor outside those two.
These come from the platform, not from this page
The rates above are what the plans hold right now, not a commercial commitment. Your own agreement can replace any of them, and the Konsole shows what is actually applied to your account.
Who pays it
By default the merchant does: the customer is charged the amount, you are credited the amount, and the fee is debited from you afterwards.
Passing bearer on POST /payments moves it. With "bearer": "customer" the payer is charged the
amount plus the fee, and you are credited the full amount you asked for. The fee is the difference,
and it never touches your balance.
The field accepts merchant or customer and nothing else. Leave it out and you get merchant.
Which bucket the fee comes out of
A collection fee is not subtracted from the credit. The payment credits your balance in full, then a separate debit takes the fee out, and that debit lands in the same bucket the payment credited.
That matters because a fresh collection sits in pending while its retention hold runs. Its fee is
taken from pending too, so a fee can never push available negative for an account whose money
has not cleared yet. Balance covers the buckets and the hold.
What a payout costs
From 1 % on Mobile Money and the other operator channels, depending on the country and the channel: the rate of each one is in your Wajub rail application. Two channels are priced differently.
| Channel | Fee |
|---|---|
wajub, to another Wajub account | None. The money never leaves Wajub |
wire, a bank transfer | A fixed fee per transfer instead of a percentage. Processed within 48 business hours by default |
The timing is the part that catches people. The fee is estimated and reserved with the principal the
moment you create the transfer, so sending 10 000 XAF puts 10 100 XAF out of reach immediately. It is
only charged for real when the payout reaches succeeded.
| The payout ends | The fee |
|---|---|
succeeded | Charged, and the reservation settles |
failed | Never charged. Principal and estimate both return to available |
A payout on your own provider carries no Wajub fee
The Wajub fee applies to payouts Wajub routes and funds. One that leaves through a provider you brought yourself is not funded from your Wajub balance, so it reserves nothing and is charged nothing here. That provider bills you directly, on its own terms.
Sandbox charges 2 % on both legs
The sandbox has its own flat rate and it is not the live one. Both a sandbox collection and a sandbox payout are charged 2 %, which makes a sandbox payout twice as expensive as the live one it is supposed to be rehearsing.
Do not port sandbox arithmetic to production
A sandbox payout fee is also charged on top of the amount rather than taken out of it, and it is not given back when the payout fails. Both differ from live. If you are writing the code that computes what a payout will cost you, write it against the live rules and test the numbers separately.
Reading a fee back
There is no fees endpoint. Nothing on the API lists them, retrieves one, or exposes a total, and
there is no fee field on a payment or a transfer either.
The only programmatic surface is the fee.charged webhook, which fires once per fee, as it is
charged. A payment whose fee the payer paid, with bearer set to customer, sends none: nothing
was charged to you.
Four things about that payload are worth knowing before you build on it.
idstringoptionalpo_ and pay_ convention.percentagenumberoptional1 means one percent. Not a fraction.applied_tostringoptionaltransaction for a collection, transfer for a payout. A collection is not called a payment here.fixed_amountnulloptionalnull on a Wajub fee. Only a platform commission can carry one, see below.The fourth thing is a gap rather than a quirk, and it will shape how you reconcile.
A payout fee does not say which payout
When the fee belongs to a collection, the event carries a payment object with its id. When it
belongs to a payout, it carries nothing of the sort: you get an amount, a currency and
applied_to: "transfer", with no way to attribute it to a transfer from the event alone. Match on
the amount and the timestamp against your own payout records, or reconcile from the Konsole.
If you are a platform
A connected account's payment can carry a second, entirely separate fee: your own commission, taken
from the Sync pricing rule you set on that account. Its type is sync_fee rather than
platform_fee, and it is the one fee on the platform that can have both a percentage and a fixed
component.
It produces two events rather than one, so both sides see the same money.
| Event | Goes to | Means |
|---|---|---|
fee.charged | The connected account | It was charged your commission |
fee.received | You | You earned it, with the account it came from |
Wajub's own platform_fee is charged on top of that, independently. Sync covers the
pricing rules and how a connected account is set up.