Audited ·Last updated 27 Jul 2026·5 citations·Tier 1·0 uses

M-Pesa Fee Calculator

Find the Safaricom M-Pesa fee for sending, withdrawing, ATM cash-outs, or free transactions by amount and tariff band.

M-Pesa Fee Calculator

Transaction type
Applicable M-Pesa fee
33.00
Total debit from sender
2,533.00
Amount received by recipient or cashed out
2,500.00
Effective fee rate
1.32

Background.

The M-Pesa Fee Calculator finds the Safaricom transaction fee for a Kenyan mobile-money payment based on amount, transaction type, and tariff bracket. The canonical user is about to send money, withdraw cash, or compare payment options and wants to know the exact debit before confirming. A KSh 2,500 send is not priced by multiplying 2,500 by a percentage. It falls into a bracket, and the fee is the fixed amount assigned to that bracket for the selected transaction type.

M-Pesa is part of daily financial infrastructure in Kenya. Safaricom's 2025 annual report states that M-Pesa revenue grew to KSh 161.1 billion, one-month active customers reached 35.82 million, and total M-Pesa transaction value reached KSh 38.29 trillion for FY25. Communications Authority of Kenya sector reports show continued growth in mobile money subscriptions and agents. Those figures explain why a fee calculator has high search demand: the charges affect routine household transfers, small-business cash flow, merchant payments, and agent withdrawals.

The non-obvious part is that M-Pesa has several fee schedules, not one universal price. Sending to a registered user, sending to an unregistered user, withdrawing from an agent, withdrawing from an ATM, paying a merchant, or using selected free services can have different treatment. Some transfers can be zero-rated. Some account or product terms can change independently. A calculator that asks only for amount will be misleading unless it also asks for transaction type and uses the matching tariff table.

The engineering model should treat Safaricom's official fee table as data. Each row needs a minimum amount, maximum amount, transaction type, and fee. The formula module then performs a deterministic lookup and computes total debit, recipient amount, and effective percentage. This separation matters because tariffs are volatile. If Safaricom changes rates or tax treatment, engineering updates the JSON table and citation date without touching the lookup function. The worked example uses explicit tariff rows so tests remain valid even if real-world rates change later.

A good user interface should show both the nominal fee and the effective rate. A KSh 33 fee on a KSh 2,500 transfer is 1.32 percent. The same fixed fee would be a much larger percentage on a smaller transfer and a smaller percentage on a larger one. Showing the effective rate helps users compare whether one large transfer is cheaper than several small ones, subject to transaction limits and safety. The calculator should not encourage fee avoidance that violates terms, but it can make price mechanics transparent.

The calculator also needs to distinguish fee estimation from transaction authorization. Safaricom's app, SIM toolkit, and confirmation screens remain the operational source of truth because account limits, temporary offers, service availability, and balance state can change. The dossier's role is narrower: define the bracket lookup and debit arithmetic so users can anticipate a charge and developers can test the behavior against a dated tariff table. That separation keeps the result useful without pretending to be a live payment system.

It also keeps compliance-sensitive payment behavior outside a static calculator.

What is m-pesa fee calculator?

An M-Pesa fee is the charge applied to a mobile-money transaction in the Safaricom M-Pesa system. The fee depends on the amount bracket and transaction type. Unlike card interchange or some bank charges, M-Pesa consumer fees are usually stated as fixed shilling amounts within ranges. A transaction can therefore move from one fee to another when the amount crosses a bracket boundary.

The calculator's base unit is Kenyan shillings. The amount is the value being sent, withdrawn, or paid. The fee is the charge. Total debit is the amount plus the fee when the customer pays the fee from wallet balance. For a send transaction, the recipient typically receives the stated amount and the sender pays the fee separately. For a withdrawal, the customer receives cash equal to the amount and the wallet is debited by amount plus fee.

The range of validity is consumer fee estimation using a current Safaricom tariff table. It does not determine account limits, reversal eligibility, fraud holds, merchant settlement timing, overdraft fees, Fuliza charges, bank-to-wallet charges, or tax reporting. It should be treated as a fee lookup and debit estimator.

Amounts should be stored as integer shillings or cents so the displayed fee reconciles exactly with the tariff row.

How to use this calculator.

  1. Enter the amount you want to send, withdraw, or pay in Kenyan shillings.
  2. Select the transaction type that matches the action you will take.
  3. Confirm the tariff table date shown by the calculator.
  4. Review the matching bracket and fee.
  5. Check total debit before confirming the transaction on your phone.
  6. If you entered wallet balance, confirm that the balance covers amount plus fee.
  7. Use Safaricom's official confirmation screen as the final authority.

The formula.

Fee = band(type, amt) ; Debit = amt + Fee

The formula is a bracket lookup. The tariff table is an ordered or searchable list of rows. Each row has a transaction type, minimum amount, maximum amount, and fee. The calculator finds the row where the selected transaction type matches and the amount lies within the inclusive range. If no row matches, the calculator should return a validation error, because the amount may be outside allowed limits or the table may be incomplete.

After the fee is found, the debit calculation depends on transaction type. For ordinary send-money and withdrawal actions where the customer pays the fee, total debit equals amount plus fee. The recipient or cash amount remains the original amount. For zero-rated or free transaction types, fee equals zero and total debit equals amount. Some product-specific transactions may have special rules; those should be represented as separate transaction types rather than conditional hacks in the formula.

Effective fee rate is not how Safaricom necessarily sets the fee, but it is useful for interpretation. It divides the fixed fee by the amount and multiplies by 100. A fixed shilling fee has a declining effective rate as amount increases within a bracket. This can make the lower end of a bracket relatively expensive in percentage terms. Showing the bracket label prevents users from thinking the fee was interpolated or computed as a hidden percentage.

If balance is supplied, sufficient balance is a simple comparison: balanceBeforeKsh >= amountKsh + feeKsh. The calculator should not subtract the amount twice or subtract fee from recipient value. Precision is straightforward because Kenyan shilling consumer fees are whole-number values in the tariff table. The implementation should still use integer cents or integer shillings internally rather than binary floating point for currency if additional percentage charges are ever introduced.

This design also makes auditing easier: changing a tariff row changes results, while the lookup and debit code remains unchanged.

A worked example.

Example

A user wants to send KSh 2,500 to a registered M-Pesa user and has KSh 3,000 in wallet balance. The tariff table supplied to the calculator has a sendRegistered bracket from KSh 1,501 to KSh 2,500 with a KSh 33 fee. Since 2,500 is within that inclusive range, the matching fee is 33 shillings. The sender's total debit is the amount plus the fee: 2,500 plus 33 equals KSh 2,533. The recipient receives KSh 2,500 because the fee is paid separately by the sender. The effective fee rate is 33 divided by 2,500 times 100, which equals 1.32 percent. Finally, the calculator checks wallet balance. KSh 3,000 is greater than KSh 2,533, so the transaction is affordable on the supplied balance. The output should show the bracket, fee, total debit, recipient amount, and sufficient-balance flag. Those fields are enough for a deterministic unit test because every number follows from the supplied row and amount.

tariff Min Ksh1,501
balance Before Ksh3,000
tariff Max Ksh2,500
amount Ksh2,500
tariff Fee Ksh33

Frequently asked questions.

Why is M-Pesa fee calculation a table lookup?
M-Pesa fees are published as fixed charges for amount ranges and transaction types. That means the calculator should not assume a continuous percentage formula. A transfer just below a bracket boundary and a transfer at the top of the same bracket can have the same shilling fee, while a transfer one shilling above the boundary may move to another fee. A table lookup exactly matches that structure and makes tariff updates easier. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.
Why does the calculator need transaction type?
Different M-Pesa actions can have different charges. Sending money, withdrawing at an agent, withdrawing at an ATM, paying a merchant, and using product-specific services are not interchangeable. If the calculator used only amount, it could return the wrong fee for the user's action. Transaction type lets the formula choose the correct tariff table. It also allows zero-fee rows to be represented cleanly rather than handled as exceptions after the fact. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.
Can the official fee change?
Yes. Safaricom can update tariffs, product terms, and fee schedules. Taxes and regulatory conditions can also affect consumer charges. The calculator should therefore display a tariff-table effective date and source. The formula itself should remain stable, but the data should be refreshable. Users should treat the Safaricom confirmation screen and official tariff notice as authoritative when a real transaction is being made. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.
What is effective fee rate?
Effective fee rate is fee divided by transaction amount, expressed as a percentage. It helps users understand the relative cost of a fixed shilling fee. For example, a KSh 33 fee on KSh 2,500 is 1.32 percent. The same KSh 33 fee on a smaller amount would be a higher percentage. This output is interpretive; it is not necessarily how the fee was set. The actual fee still comes from the bracket table. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.
Does the recipient receive less because of the fee?
For the ordinary send-money model in this dossier, the recipient receives the entered amount and the sender pays the fee on top. A KSh 2,500 send with a KSh 33 fee debits KSh 2,533 from the sender and credits KSh 2,500 to the recipient. Other transaction types may have different settlement details, so the calculator should label total debit and recipient or cash amount clearly. It should not hide the fee inside the sent amount unless a specific product requires that treatment. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.
Does this calculator include Fuliza charges?
No. Fuliza is an overdraft service with its own terms, access rules, and charges. A basic M-Pesa fee calculator estimates the transaction fee for the selected action. If the user lacks sufficient wallet balance and uses Fuliza, additional charges may apply. Those should be modeled in a separate Fuliza mode or calculator, with its own tariff and terms citations. Mixing ordinary transfer fees and overdraft fees would make the output ambiguous. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.
What if my amount is outside the table?
The calculator should return a validation warning rather than guessing. An amount outside the table may be below the minimum transaction amount, above the maximum allowed transaction amount, or missing because the data configuration is incomplete. Guessing by extending the nearest bracket would be dangerous because transaction limits and fees are policy decisions, not mathematical trends. Engineering should require an explicit matching row for every valid amount. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.
Why should fees be stored as data instead of code?
Storing fees as data makes tariff updates auditable. A JSON table can include source URL, effective date, transaction type, bracket bounds, and fee. The formula module then performs the same lookup regardless of when rates change. If rates are hardcoded in code branches, updates become error-prone and tests can silently encode stale fees. Data-driven tariffs also let the calculator show the user which table version produced the result. The calculator should display the governing assumption beside the answer so users can audit the number instead of treating the output as an unexplained recommendation.

In this category

Embed

Quanta Pro

Paid features are coming later.

  • All 313 calculators remain free
  • No billing is enabled
Coming soon