How Mobile Money Payments Work at Checkout in Seven African Markets

If you are planning to accept wallet payments in more than one African country, the hard part is not the idea. It is the detail: which wallet applies in which market, how the customer confirms, and how your system learns the result. This article works through those details in order. For a method-by-method overview, see the mobile money payment gateway page.

• Each of the seven markets has its own set of local methods. No single wallet covers all of them.
• Confirmation usually happens on the customer's phone, outside your checkout, so status handling matters more than with a simple form submission.
• Collecting from customers, paying out to them and settling funds to you are three separate flows. Plan each one on its own terms.
• You can connect through an API (host-to-host) or a Hosted Payment Page. Both are ways to reach the same gateway, not different products.
• Settlement is dispatched same-day (T+0); bank posting times vary.

A gateway sits between your website and the payment methods your customers already use. Your checkout sends one request to the gateway. The gateway routes it to the right local method, tracks the outcome and reports back to you.

Without that layer, a merchant expanding into several countries would need a separate technical and commercial relationship for each wallet. That means separate formats, separate status logic and separate reconciliation. A single gateway reduces this to one integration and one reporting model, while still respecting how each local method works.

Payment Gateway Africa is a payment gateway for African markets that handles pay-ins and payment processing, plus payouts where available for the method and project. The rest of this guide uses its supported markets and methods as the working example.

One point is worth stating early. A gateway does not change how a wallet works for the customer. If a method asks the customer to confirm with a PIN on their phone, that step remains. The gateway's job is to start the request correctly, wait for the result and pass it to you in a consistent form.

The exact steps vary by method, but most wallet payments follow a similar path from order to confirmed status.

1. The customer picks a local method at checkout and, where needed, enters the phone number linked to their wallet.
2. Your system sends the payment request to the gateway, either directly through the API or by redirecting the customer to the Hosted Payment Page.
3. The gateway passes the request to the selected method.
4. The customer confirms on their own device. With M-Pesa in Kenya, for example, a payment prompt appears on the phone and the customer approves it with their PIN.
5. The method returns a result to the gateway.
6. The gateway sends the final status to your backend, and your system updates the order.

Step 4 is where wallet payments differ most from a typical web form. The customer leaves your page, at least mentally, to approve on their phone. They may take a moment, switch apps, or not complete the approval at all. Your checkout should show a clear waiting state and should not treat a closed browser tab as a failed payment. The status your backend receives is what counts.

The table below lists the methods currently supported in each market, together with the local currency. Use it as a planning reference. Availability for your specific project is confirmed during onboarding.

Two patterns stand out. First, some brands appear in more than one market. Orange Money covers Senegal, Mali and Guinea, and Wave covers Senegal and Mali. Even so, treat each country as its own configuration: currencies differ (Guinea uses GNF, while Senegal and Mali use XOF), and so can customer habits.

Second, some markets offer several options. Ethiopia and Mali each have three. Offering the full set in those markets lets customers use the wallet they already hold instead of abandoning checkout.

Kenya. M-Pesa is the supported method, and the payment prompt with PIN approval on the customer's phone defines the experience. Design your checkout around that waiting moment. The Kenya payment gateway page covers the market in more depth.

Egypt. Wallets are registered against a mobile number, so the phone number is the key input at checkout. Validate the format before submitting a request to cut down on avoidable failures.

Ethiopia. Customers can pay with CBE Birr, M-Pesa (Ethiopia) or local transfers. CBE Birr is a bank-linked option that supports purchases. Present all three clearly, because a customer who doesn't see their usual method may leave.

Senegal and Mali. Both use XOF and both support Wave and Orange Money. Mali also supports Moov Money. If you sell in both countries, you can share much of your checkout design while keeping separate method lists.

Guinea. Orange Money is the supported method and amounts are in GNF. With a single method, the checkout can be very direct: one clear option, one phone number field.

Tunisia. D17 is linked to the e-Dinar and supports payments to sellers. Flouci is a digital wallet. Offering both gives Tunisian customers a choice between two familiar local options.

Each market has its own central bank and its own rules. This guide doesn't replace legal advice. If you handle customer personal data, check your obligations in each country where you operate.

Merchants often talk about "payments" as one thing. Operationally, there are three flows, and mixing them up leads to reconciliation problems.

Pay-ins are payments from your customers to you, such as a customer paying for an order with Wave or D17. This is the flow most of this guide describes.

Payouts are payments from you to customers or recipients, such as refunds paid to a wallet or earnings sent to sellers on a marketplace. Payouts are offered where available for the method and project, so confirm them for each market before you build a product feature around them.

Settlement is the transfer of collected funds from the gateway to your business. Payment Gateway Africa dispatches settlement same-day (T+0). Mind the distinction: T+0 refers to when settlement is dispatched. Bank posting times vary, so the moment funds show in your account also depends on your receiving bank.

Keep separate records for each flow. A pay-in has one reference, a payout has another, and a settlement batch groups many transactions. Matching these cleanly in your ledger is much easier if they were never merged in the first place.

There are two ways to connect, and the choice depends mostly on how much of the checkout you want to control.

Host-to-host (API). Your backend talks to the gateway directly. You build the method selection and phone number capture into your own interface and handle each step in your code. This suits teams that want full control of the checkout design and already run a backend capable of handling asynchronous status.

Hosted Payment Page. You redirect the customer to a payment page provided by the gateway, which presents the methods and collects the details needed. When the payment is done, the customer returns to your site. This suits teams that want to launch faster or reduce how much payment logic they maintain.

Either path supports the same markets. Host-to-host is a direct integration, not a white-label product. Some merchants start on the hosted page to validate demand in a new country, then move to the API later.

Whichever you choose, the customer journey runs in the browser through a payment page or your own web checkout. If you have a mobile app, plan for that browser-based step rather than expecting an embedded native component.

Because wallet confirmation happens on the customer's phone, your system cannot rely on the browser to report the outcome. The gateway sends payment status to your backend through postbacks and webhooks. These notifications go to you, the merchant. The gateway doesn't send separate notifications to your customers, so any receipt or confirmation message to the buyer is yours to send.

A few habits make status handling dependable:

• Treat the server-side notification as the source of truth, not the customer's return to your site.
• Make your handler idempotent, so a repeated notification for the same transaction does not create a duplicate order.
• Show customers a pending state while approval is outstanding, and update it when the final status arrives.
• Log every notification with its transaction reference for later reconciliation.

For context on overall performance: our overall transaction success rate is 85%, measured as successful transactions divided by all transactions. That is a product-wide figure, not a number for any single country or method. Unapproved prompts and incorrect phone numbers are among the reasons any wallet payment may not complete, which is why clear checkout guidance matters.

Before committing to a provider for wallet payments, work through questions like these with your product, finance and engineering teams.

• Coverage: Does the provider support the full list of local methods in each target country, or only the best-known one?
• Flows: Are pay-ins, payouts and settlement clearly separated, and are payouts confirmed for the methods you need?
• Settlement timing: How is settlement timing defined? Is it the time funds are sent, or the time they arrive?
• Integration options: Can you start on a hosted page and move to an API later without changing provider?
• Status delivery: How are results delivered to your backend, and what does a notification contain?
• Expansion cost: What does it cost to add methods later?

A note on that final point: for existing merchants, activating additional supported payment methods carries no connection surcharge, and method count has no impact on their connection price. For a current client, switching on a method we already support can take up to one day. This covers expanding an existing setup only. It says nothing about onboarding new merchants or about transaction pricing.

Launching seven countries at once is rarely the best plan. A phased approach reduces risk and gives your team real data early.

1. Pick a first market where you already have demand. For many merchants that is Kenya, because a single method, M-Pesa, covers the market.
2. Complete onboarding and business verification so your project can be configured for live traffic.
3. Build and test the checkout, the pending state and the status handler in a test project before going live.
4. Go live in one market, watch completion and support tickets, and refine your phone-number prompts and messaging.
5. Add neighbouring markets that share characteristics. Senegal and Mali share XOF and two methods, which makes them a natural pair.
6. Enable additional methods in markets where customers use more than one wallet, such as Ethiopia or Tunisia.

When you are ready to compare methods side by side, the overview of supported mobile wallets brings every method and market together on one page. To discuss your project, start from the Payment Gateway Africa homepage.