What it is
M-PESA is a mobile money service, not a bank account and not a card. Customers hold a balance tied to their mobile number, move cash in and out through agent points, and pay merchants using a till number, a PayBill business number or a QR code. Safaricom operates it in Kenya under Central Bank of Kenya oversight, and Vodacom and other operators run versions of it in neighbouring markets. For merchants, M-PESA is a payment method you accept. You reach it either through Safaricom's own business products, such as PayBill and Buy Goods till numbers, or through the Daraja API, or through a PSP that has done that work for you.
- M-PESA is a mobile money service rather than a bank account or a card scheme.
- Customers hold a balance tied to a phone number and move cash in and out at agent points.
- Merchant payments use a till number, a PayBill business number or a QR code.
- Safaricom runs it in Kenya under Central Bank of Kenya oversight, with other operators elsewhere.
Where it is used
M-PESA is strongest in Kenya, where it is the default way a large share of the population pays for almost anything, and it also runs in Tanzania, Mozambique, the Democratic Republic of Congo and Ethiopia through different operators. It settles in local currency, Kenyan shillings in Kenya. The customer base spans people with and without bank accounts, and the agent network is what makes it work in areas where bank branches are rare. For a merchant entering East Africa, M-PESA is not an alternative to cards in the way it might be in Europe. It is the primary method, and cards are the alternative.
- M-PESA is strongest in Kenya and also runs in Tanzania, Mozambique, the DRC and Ethiopia.
- It settles in local currency, with Kenyan shillings in the Kenyan market.
- The customer base includes people with and without bank accounts.
- Agent networks make it work where bank branches are rare.
Which businesses it suits
M-PESA suits businesses selling to East African consumers at low to medium ticket sizes. Retail, e-commerce, utilities and bill payments, transport, agriculture payments, digital content, gaming and microlending collections all fit. It also suits businesses that need instant confirmation before releasing goods or credit, since payments confirm in seconds. It suits you less if your model depends on card instalments or credit, because that is not what the product does. It is also a weaker fit for very large single payments, since per-transaction and balance limits apply, and for corporate buyers who would rather pay by bank transfer.
- M-PESA suits retail, e-commerce, bills, transport, agriculture, content, gaming and lending collections.
- Instant confirmation makes it practical for releasing goods or credit immediately.
- It does not offer instalments or credit, so card rails cover that need.
- Large single payments and corporate buyers fit bank transfer better.
How merchants usually connect
Kenyan businesses can take the direct route: register a PayBill or Buy Goods till number with Safaricom and integrate the Daraja API, which handles customer-to-business payments, validation callbacks and confirmations. Cross-border merchants usually take a different path, working through a PSP such as dLocal or Flutterwave that already holds the M-PESA connection and exposes it inside a regional checkout. Onboarding needs company registration, identification for directors, a local bank account or a partner account, and a review of your business. Ask how callbacks and reconciliation are handled, because M-PESA confirms arrive asynchronously and your system has to match them to orders.
- Kenyan entities can register a PayBill or till number and integrate the Daraja API directly.
- Cross-border merchants usually work through a PSP that already holds the M-PESA connection.
- Onboarding needs company documents, director identification, a bank account and a business review.
- Ask how callbacks and reconciliation work, since confirmations arrive asynchronously.
Cross-border merchant notes
Without a Kenyan entity you will not hold a direct Safaricom contract, so you onboard under a PSP or a local partner, collect in shillings, and settle to a Kenyan account before repatriating under Central Bank of Kenya and foreign exchange rules. Interoperability is the other theme to plan for. Mobile money interoperability between operators is expanding across East Africa, but coverage is uneven and depends on the corridor, so confirm whether a payment from a non-Safaricom wallet will actually reach you. Agent cash-out also matters in reverse: customers who reverse a purchase may expect cash, and your refund policy has to say what happens.
- Without a Kenyan entity you onboard under a PSP or local partner and collect in shillings.
- Repatriation happens under Central Bank of Kenya and foreign exchange rules, so model the timing.
- Mobile money interoperability varies by corridor, so confirm non-Safaricom wallets can reach you.
- Agent cash-out expectations mean your refund policy should state how reversals are handled.
Fees, settlement and refunds
Treat any published rate as a starting point only. Real pricing shifts with country, industry, volume, settlement currency, integration method and contract terms. Verify against the operator's official pricing page or a written quote before you commit. Structurally, expect a transaction fee, a withdrawal or cash-out fee and a fee on refunds, quoted by Safaricom or by your PSP. Payments confirm in seconds, and settlement follows the schedule your provider sets. Refunds are reversals to the customer's mobile money account rather than card chargebacks, and they need a manual or API-driven process, so agree response times with your partner.
- Treat published rates as a starting point and verify the real price on the official page or in a quote.
- Expect a transaction fee, a withdrawal fee and a refund fee, set by Safaricom or your PSP.
- Payments confirm in seconds, with settlement following your provider's schedule.
- Refunds are reversals to the mobile money account, so agree response times with your partner.
Alternatives and complements
Airtel Money is the main alternative in Kenya and across East Africa, and adding it covers customers who sit on a different operator. Local card acquiring is worth adding for higher ticket sizes and for buyers who want credit or instalments, though card penetration is far lower. Bank transfer suits corporate and wholesale orders above mobile money limits. If you operate in several African markets, a regional PSP is usually the better structure than separate country integrations, because it gives you M-PESA, Airtel Money, cards and bank transfer through one contract and one reconciliation format.
- Add Airtel Money to cover customers who sit on a different mobile operator.
- Add local card acquiring for higher ticket sizes and for buyers who want credit.
- Use bank transfer for corporate and wholesale orders above mobile money limits.
- A regional PSP beats separate country integrations when you sell in several markets.
Questions to ask before you integrate
Ask whether you will use a PayBill number, a till number or a PSP-hosted flow, because the reconciliation work differs. Ask for the settlement currency, the payout schedule and the minimum payout amount. Ask how refunds are initiated and how long the customer waits. Ask about per-transaction and daily balance limits against your average order value. Ask how failed or timed-out payments are handled, since customers often believe they have paid when they have not. Ask whether payments from other operators' wallets are supported. Finally, ask for a sandbox and test callbacks before you build production logic.
- Will you use a PayBill number, a till number or a hosted PSP flow, and how does reconciliation differ?
- What is the settlement currency, the payout schedule and the minimum payout amount?
- How are refunds initiated, how long do they take, and what do they cost?
- Are payments from other operators' wallets supported on your corridor?
- Is there a sandbox with working callbacks before you build production logic?
Questions merchants ask
Is M-PESA a bank account?
No. M-PESA is a mobile money service where customers hold a balance tied to their phone number, operated by Safaricom in Kenya under Central Bank of Kenya oversight. Cash moves in and out through agent points rather than branches. Merchants collect using a PayBill number, a till number or a QR code.
Can a foreign merchant accept M-PESA payments?
Not usually on a direct contract with Safaricom. A foreign business normally onboards with a PSP or local partner that already holds the M-PESA connection, collects in Kenyan shillings, and settles to a Kenyan account. Repatriation then happens under Central Bank of Kenya and foreign exchange rules, so plan for conversion and timing.
What is the difference between PayBill and a till number?
A PayBill number takes payments to a business account and carries an account reference, which suits invoices, utilities and collections where you must match a payment to a customer. A Buy Goods till number is simpler and suits retail checkout. Ask your provider which one fits your model before you build the reconciliation.
How fast is M-PESA settlement?
The payment confirms to the customer in seconds. Settlement into your bank account follows the schedule your bank, Safaricom or PSP applies, commonly the same day or the next business day. Weekends, public holidays and your own risk profile can shift it, so get the payout schedule in writing.
How do M-PESA refunds work?
Refunds are reversals to the customer's mobile money account rather than card chargebacks, so there is no representment process. They are usually initiated through an API call or a partner dashboard and carry their own fee. Agree a response time with your provider, because customers in Kenya expect fast reversals.
Should I add Airtel Money as well?
Yes, once M-PESA is stable. Airtel Money is the other large mobile money service in Kenya and across East Africa, and a meaningful share of customers use one operator and not the other. A regional PSP can often switch both on together, which is simpler than two separate integrations.