Skip to main content
Use a mobile money charge when you already know the customer’s phone number, currency, and operator. This is a direct API flow where your application owns the payment form.

Happy path

1

Initiate the charge

Send the amount, currency, phone number, and your externalReference.
2

Customer approves

They approve the prompt, or complete an OTP or redirect step.
3

Wait for the outcome

Listen for the final webhook, or query the transaction status.
4

Fulfil

Only once chargeStatus is successful.

1. Initiate the charge

Send a request to Mobile Money Charge.
If currency is not KES, momoOperatorId is mandatory. Find the code for the customer’s network on the mobile money operators page.
Response
Track the transaction with the returned transactionId or your own externalReference.
Some operators require the customer to generate a one-time payment code on their handset before you initiate the charge. Follow the operator’s customer instructions for that market, then send the generated code as otpCode in the charge request.This is different from the stepRequired: otp flow in step 4, which happens after initiation.
successRedirectUrl and failureRedirectUrl apply to redirect-capable rails such as Wave in Senegal (XOF). Operators that complete through STK, OTP, USSD, or a provider prompt may ignore these fields entirely.Always confirm the final status through a webhook or Get Transaction — never treat a redirect return as confirmation.
If walletCountry is omitted and walletCurrency matches currency, the country is resolved from the customer’s phone number. If walletCurrency differs from currency, the wallet currency default is used where supported, such as USDUS.Pass walletCountry explicitly when settling into a non-default supported wallet country, and always pass it when walletCurrency is XOF.

2. Check the transaction status

Verify before providing value. Call Get Transaction with either the transactionId or your externalReference.

3. Handle webhooks

Configure a webhook URL so status changes are pushed to you instead of polling. See Getting started with webhooks.
When stepRequired is present, act on it:
  • otp — prompt the customer for the code they received, then continue to step 4.
  • redirect — send the customer to redirectUrl, then continue to step 5.

4. Validate an OTP

If you receive stepRequired: "otp", collect the code from the customer and submit it to Validate OTP.
Response
After successful validation the transaction keeps processing in the background. You will get a final successful or failed webhook when it completes.

5. Handle redirects

When stepRequired is redirect:
1

Extract the URL

Take redirectUrl from the webhook or the Get Transaction response.
2

Redirect the customer

They complete authorisation on the provider’s or bank’s secure page.
3

Wait for the final webhook

A transaction_updated event with successful or failed is the real outcome.
If you supplied successRedirectUrl and failureRedirectUrl, the provider may bounce the customer back to one of them. Treat that as a navigation event, not payment confirmation — the customer’s browser landing on your success page does not mean funds moved.

Refunds

A successful mobile money deposit can be reversed through Refund Deposit.