Payment Gateway Ethiopia

Payment Gateway Africa helps merchants accept payments in Ethiopia through supported local methods. Ethiopia is one route inside our wider payment gateway in Africa, which covers seven markets through a single integration.

On this page we cover the full set of methods we support in Ethiopia and how a payment moves from your checkout to a confirmed order. We also cover what you can run in ETB, how to connect, and what onboarding involves. Product details stay within what we can confirm today. Anything still under review with our team is not presented as available.

The confirmed method list for Ethiopia has three entries: CBE Birr, M-Pesa (Ethiopia) and local transfers. Which of them are enabled for your project is confirmed during onboarding, based on your business and use case.

Currency: Ethiopian birr, ISO code ETB. Pay-ins on the Ethiopian route are processed in ETB.

Local methods supported by Payment Gateway Africa: CBE Birr, M-Pesa (Ethiopia) and local transfers.

Regulator: the National Bank of Ethiopia (NBE). NBE oversees payment instruments in the country and lists M-PESA Ethiopia among them.

CBE Birr: this wallet service is run by the Commercial Bank of Ethiopia. The bank describes CBE Birr as a way for customers to pay for purchases.

Typical confirmation: the customer approves the payment inside their own wallet or banking channel. The exact screens depend on the method and on the customer's account.

We do not publish market penetration figures, user counts or approval rates for Ethiopia. Plan your launch around your own traffic data and the methods your customers already ask for.

Step 1 — Order created. The customer reaches checkout on your site or platform. Your backend creates a payment request in ETB with an amount, an order reference and your project ID.

Step 2 — Method chosen. The customer selects CBE Birr, M-Pesa (Ethiopia) or a local transfer. You can show the selection yourself through the API, or let our hosted payment page present it.

Step 3 — Customer details. The customer provides the details the selected method requires. The exact fields depend on the method and are confirmed during integration.

Step 4 — Payment completed. The customer completes the payment as the selected method requires. The exact screens depend on the method and on the customer's account.

Step 5 — Status to the merchant. Once the outcome is known, Payment Gateway Africa sends a postback or webhook to your server with the final status. Your system updates the order. Status messages go to you, the merchant. We do not run a separate notification service for your customers.

Step 6 — Fulfilment. You release the goods, credit the account or confirm the booking based on the status you received. Do not rely on the customer returning to your site from the browser.

Payment Gateway Africa treats three money movements as separate flows. Each one has its own logic and reporting.

Pay-ins are payments from your customers to you. In Ethiopia you can collect through CBE Birr, M-Pesa (Ethiopia) and local transfers, each processed in ETB. A useful starting point is our mobile money overview, which explains how wallet payments work across our markets.

Payouts are transfers from you to your customers, sellers or partners. Examples include marketplace seller earnings and customer refunds. Payouts are offered where available for the method and project. Confirm with our team which Ethiopian methods support payouts for your use case before you design product features around them.

Settlement is the transfer of funds Payment Gateway Africa has collected on your behalf to you, the merchant. Payment Gateway Africa dispatches each settlement on the day of collection (T+0). This timing covers dispatch only. It does not guarantee when the funds will appear in your account, because bank posting times vary.

Reporting covers your transactions, so finance and support teams can reconcile orders against statuses. Keep your order reference in every request. That makes matching postbacks, reports and settlements straightforward.

Expanding your setup later is straightforward. If you already work with Payment Gateway Africa, you can activate any additional supported payment method with no connection surcharge. Your connection price stays the same however many methods you enable. For example, if you go live with CBE Birr and decide to add M-Pesa (Ethiopia) afterwards, activating a method we already support is often done within one day for existing clients.

There are two ways to connect. They reach the same product and the same methods; they are not separate offers.

Hosted Payment Page: you redirect the customer to a payment page served by Payment Gateway Africa. The page shows the Ethiopian methods enabled for your project, collects what each method needs and returns the customer to your site. This is usually the fastest route to launch, because you build less checkout interface.

H2H (API): your server talks directly to our API. You control the method selection screen and the whole customer experience inside your product. Choose this when you need custom flows or have several brands on one platform. It is also the fit when your checkout must match a strict design system. H2H is a direct connection between your backend and ours; it is not a white-label product.

Both options use the same status model. You receive postbacks or webhooks for each payment and update your records from them. Customer-facing confirmation happens in the browser and in the customer's own wallet or banking channel.

Request formats, status handling and test scenarios are covered in our integration guide for hosted page and API. The full API reference and credentials are provided after merchant onboarding.

Before your Ethiopian project goes live, we run a know-your-business (KYB) review. Expect to share information about your legal entity, ownership, business model, website and the products or services you sell. We will also ask which countries and methods you plan to use.

Local rules apply to payments in Ethiopia, and wallet and bank operators may have their own acceptance policies. During onboarding we check whether your business and use case fit the Ethiopian methods you have requested. We may ask for more detail if something needs clarifying.

Our AML and KYC requirements explain the checks in more depth, along with what we expect from merchants after launch. For questions about your own obligations as a data controller or a regulated business, take local legal advice. Our onboarding does not replace it.

When the review is complete, you receive a test project, run your integration against it and then switch to live processing. You can start the process on our merchant onboarding page.

We prepare pricing per project rather than publishing one rate card for every market. Your quote depends on factors such as the operations you need and your expected volumes. Your business profile is also part of the assessment.

Adding further supported methods does not change your connection price. For an existing merchant, adding another supported Ethiopian method carries no extra connection fee. The Payment Gateway Africa pricing overview covers what goes into a quote and how to request one.

The same integration and status model carry across all Payment Gateway Africa markets. Our team will confirm what is needed to enable another country for your project.

Also available in Kenya: collect KES through M-Pesa with our Kenyan M-Pesa gateway. Also available in Egypt: accept EGP through mobile wallet payments in Egypt, where customers pay from wallets linked to their phone number.

For the full list of markets, currencies and methods, see our African payment markets directory.

Tell us about your product, the Ethiopian methods you want to offer and how you prefer to connect. We will guide you through KYB, set up a test project and help you move to live ETB pay-ins through the Ethiopian methods confirmed for your project.