Skip to navigation

Ethiopia Mobile Money

Mobile money operators for Ethiopia payers

Mobile money in Ethiopia (ETH) is available through the operators below. Set payerDetails.location to ETH on the checkout session and pass the operator’s provider slug on the payment; GET /v1/payment/available-methods returns the live list for the country.

For how a payment works, what you collect, sandbox testing, and error codes, see the Mobile Money overview. For the end-to-end API sequence, see Direct API: Mobile Money.

Operators

OperatorpaymentDetails.providerApproval flow
TelebirrtelebirrHandset prompt (USSD push, PIN)
M-Pesa (Safaricom Ethiopia)mpesaHandset prompt (USSD push, PIN)
CBE BirrcbebirrHandset prompt (USSD push, PIN)
Coopay E-BirrebirrHandset prompt (USSD push, PIN)
AwashBirrawashbirrHandset prompt (USSD push, PIN)
YaYa WalletyayaHandset prompt (USSD push, PIN)

Ethiopia mixes carrier wallets (Telebirr, M-Pesa) with bank-issued ones (CBE Birr, Coopay E-Birr, AwashBirr) and an independent PSP wallet (YaYa). All six use the same handset-prompt flow, so a single integration covers them: the customer approves the debit on their handset and there is no POST /payment/authorize step. None of them use the redirect flow.

The mpesa slug here is Safaricom Ethiopia, a different wallet from the Safaricom Kenya product that shares the slug in Kenya. The slug is scoped by the session’s payerDetails.location, so there is nothing extra to pass.

ETB only

Ethiopian mobile money collects in ETB. Set currency (or collectionCurrency on an FX-enabled session) to ETB when you create the session. A payment that reaches these operators in any other currency is rejected with INVALID_CURRENCY rather than converted.

Payouts and refunds

  • Payouts go to four of the six wallets: telebirr, mpesa, cbebirr and yaya, plus Ethiopian bank accounts. ebirr and awashbirr are collect-only and are rejected as payout destinations. See Supported Destinations and Mobile Wallet.
  • Refunds use the provider refund route in the Refunds guide: the refund goes back against the original payment, whichever of the six wallets it came from.

Collections themselves behave exactly as they do elsewhere: subscribe your endpoint to the transaction.* events and route on the delivered status, since the webhook body carries no event type. See Webhooks for delivery and signature verification, and Webhook Events for the full catalogue and payload schemas. Alternatively, poll GET /v1/payment/{transactionId}.