Cash out

Sending money to an MTN MoMo or Airtel Money wallet: supplier payments, salaries, marketplace payouts, winnings. No prompt, no approval. It arrives.

The endpoint

POST/v1/payoutsApp key

Send money

curl https://api.xendlypay.com/v1/payouts \
  -H "Authorization: Bearer $XENDLY_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: supplier-payment-88" \
  -d '{
    "amount": 25000,
    "msisdn": "0788924941",
    "description": "Supplier payment"
  }'

The body is the same shape as a cash in. The difference is the direction of travel, and everything that follows from it.

Cash out is not cash in backwards

	Cash in	Cash out
Who approves	The customer, on their handset	Nobody. It leaves.
Reversible	Yes, refund it	No. Once it lands, it is theirs.
Needs a verified business	No, test mode works immediately	Yes, always
Funded by	The customer's wallet	Your available balance
Typical settle time	seconds after approval	seconds

There is no undo

A payout to a wrong number is a wrong number that now has your money. We cannot pull it back, and neither can MTN or Airtel. Validate the destination before you send, and if a human typed it, show it back to them first.

Who is allowed to

Three gates, checked in this order:

The business is verified. An RDB certificate and a TIN, reviewed by a person. Until then every payout answers 403, whatever the key says.
The app is live and active. Test-mode payouts are simulated. See test mode . A disabled app cannot transact at all.
The balance covers it. Amount plus fee, against money that has already settled. Pending collections do not count.

Why the extra gate on this direction

Taking money is self-limiting: the worst a bad actor achieves is annoying strangers with prompts nobody approves. Sending money is the direction fraud actually travels, and “we verified them afterwards” is not a sentence that helps anyone. Being asked for a certificate before your first payout is the whole of the friction.

When the balance will not cover it

409 Conflict

{
  "status": "error",
  "message": "insufficient balance: 12,500 RWF available, 25,300 RWF needed",
  "timestamp": "2026-09-12T09:14:02.000Z"
}

Checked before anything is sent, so a refused payout leaves no transaction and no half-state. The number needed includes the payout fee. If you send exactly your available balance, the fee is what pushes it over.

Read the balance first if you are batching: balance and withdrawals.

Paying yourself

Moving your own earnings to your own number is a withdrawal: the same machinery, a different button, and it goes to the payout number on your account rather than one chosen per request. Do it from the dashboard. It shows up in your transaction list as a cash out marked dashboard, so your ledger is one list, not two.

Minimums

100 RWF is the floor we impose. The networks impose their own ceilings per transaction and per day, and IntouchPay, the rails underneath, may impose a floor of its own on disbursements. When it does, the refusal comes back as a 400 naming the minimum rather than a generic failure.

← Cash in Refunds →