Skip to content

Automating Payouts With M-Pesa B2C: Salaries, Suppliers and Refunds

Collecting money from customers is only half of M-Pesa. The B2C API lets your system pay people out - wages, refunds, commissions - automatically. Done wrong, it is also the riskiest thing you can automate.

By Karani Geoffrey, Founder & CEO, Upeosoft
In short

M-Pesa B2C (Business to Customer) is the Daraja API that sends money from your business short code out to customers' or staff's phones. It powers automated salaries, supplier payments, refunds and commissions. It needs an initiator name and a security credential, funded float, and strict approval controls because it moves real money out of your account.

Key takeaways
  • B2C is the reverse of collection: your system pushes money out to a phone number automatically.
  • It requires an initiator user and a security credential generated from an encrypted password, plus a funded B2C float.
  • Because it moves money out, payout automation needs approval limits and maker-checker controls, not just working code.
  • Every payout returns a result via callback - you must record it and never assume a request succeeded.
  • Common uses: payroll, supplier settlements, sales commissions, insurance and refund disbursements, loan payouts.
  • Reconciliation matters as much here as on collection: match every payout to its source record and confirm it landed.

The half of M-Pesa most businesses ignore

Almost everyone integrates collection - taking money in. Far fewer automate the other direction. Yet paying money out is where the manual effort and the errors pile up: an accountant sending salaries one phone number at a time, refunds handled by WhatsApp, commissions calculated in a spreadsheet and paid by hand.

The B2C (Business to Customer) API automates all of it. Your system sends money directly to a phone number - a salary, a refund, a supplier payment, a commission - as a normal part of a workflow, no manual sending required.

How B2C is different from collection

Collection APIs (STK Push, C2B) bring money in and are relatively forgiving - a failed collection just means no sale. B2C sends money out, and a mistake means money gone.

That difference drives everything. B2C needs stronger credentials: an initiator user and a security credential built by encrypting the initiator password with Safaricom's certificate. It draws from a separate float. And it demands controls that collection never needs, because the failure mode is not 'we lost a sale' but 'we paid the wrong person the wrong amount, automatically, at scale.'

What you can automate with it

Once B2C is wired into your systems, a lot of manual money movement disappears.

  • Payroll and casual wages, paid straight from your HR or payroll system on payday.
  • Supplier and contractor settlements, triggered when an invoice is approved.
  • Sales commissions and agent payouts, calculated and disbursed automatically.
  • Customer refunds and cancellations, without an accountant sending each one by hand.
  • Loan disbursements, savings withdrawals and insurance payouts for financial services.
  • Promotions, rebates and winnings, paid instantly instead of by manual list.

The controls that make payout automation safe

Automating outbound payments without controls is how businesses get drained - by a compromised credential, a bug in a loop, or a malicious insider. The controls are not optional.

Set per-transaction and daily ceilings so no single payout or day can exceed a sane amount. Require maker-checker approval for batches, so one person prepares a run and another releases it. Keep the initiator credential in a secrets manager, never in code or a shared file. Whitelist the server IPs Safaricom will accept requests from. And alert a human on every payout, or at least every batch, so anomalies are seen within minutes rather than at month-end.

Handling results, failures and retries

B2C is asynchronous, and the outcome you care about arrives on a callback after the request, not in the immediate response. A payout can fail because the number is unregistered, the recipient's account has limits, the float is empty, or the network hiccuped.

Your system must hold each payout as pending, apply the result callback to mark it paid or failed, and store the M-Pesa receipt on success as proof. Retries are where double-payments happen: build them to retry only genuine failures, keyed so the same payout can never be sent twice. This idempotency discipline is the difference between a reliable payout system and one that occasionally pays a supplier twice.

Float, limits and reconciliation

Two operational realities trip up new B2C users. First, float: payouts draw from a separate balance you must keep topped up, or payday fails while your collection account is full. Automate a low-float alert at minimum. Second, limits: B2C has rate and value ceilings, so bulk runs must be throttled and large single payouts checked against caps.

Then reconcile. Every payout should tie back to its source - the payslip, the invoice, the refund request - and be confirmed landed. A B2C system that pays money out but does not reconcile is just a faster way to lose track of your cash.

How Upeosoft builds B2C payout systems

We build payout automation with the controls first, not bolted on later: approval workflows, per-transaction and daily limits, secure credential handling, IP whitelisting, and alerting on every disbursement. We wire result callbacks so nothing is ever assumed paid, add idempotent retries so failures never double-pay, and reconcile each payout back to your payroll, ERP or refund records.

Whether you want to automate payday, supplier settlements or refunds, talk to Upeosoft and we will build a payout system you can trust to move money without you watching it.

Frequently asked questions

What do I need to start using the M-Pesa B2C API?

You need a business short code enabled for B2C, an initiator username, and a security credential - an encrypted version of the initiator's password generated with Safaricom's public certificate. You also need a funded B2C float account, because payouts draw from a separate utility balance, not your collection account. Finally you need result and timeout callback URLs that are public, HTTPS and reliable.

What is a B2C float and why does it matter?

Money you collect and money you pay out sit in different M-Pesa balances. To send B2C payments you must top up a working or utility account with enough float to cover the payouts. If the float runs dry, payouts fail even though your business is holding plenty of money elsewhere. Automating a top-up alert, or the top-up itself, prevents payday failing silently.

Is it safe to automate salary and supplier payments?

It is safe when you build controls around it. The danger is not the API - it is that automated outbound money, if compromised or misconfigured, drains fast. Safe automation means per-transaction and daily limits, maker-checker approval for batches, tight control of the initiator credential, whitelisted server IPs, and alerts on every payout. With those in place, automation is safer than manual bulk payments because it removes typing errors.

How do I know a payout actually reached the person?

B2C is asynchronous. You send a request, get an acknowledgement, and the real outcome - success, failure, or the recipient being unregistered - arrives later on your result callback. Your system must treat a payout as pending until that callback confirms it, record the M-Pesa receipt on success, and flag failures for retry or review. Assuming success on the acknowledgement is how businesses think they paid someone who never received a shilling.

Can I run bulk payroll through B2C?

Yes. Payroll, commissions and supplier runs are the classic use. Your system loops through the batch, sends each B2C request, and reconciles each result back to the employee or supplier record. The important additions for bulk are batch approval before sending, throttling to respect rate limits, a clear record of which items succeeded and failed, and a safe way to retry only the failures without double-paying anyone.

Karani Geoffrey
Karani Geoffrey
Founder & CEO, Upeosoft

Karani Geoffrey is the Founder & CEO of Upeosoft, a software and automation company rooted in Kenya. He builds custom software, AI systems, and production-grade ERPNext for businesses across East Africa, and writes about the Kenyan realities - eTIMS, M-Pesa, SHIF, unreliable internet and power - that make or break real systems.

Next step

Want this working in your business?

Upeosoft builds and hardens the systems behind this article - for real Kenyan operations, with eTIMS, M-Pesa and offline realities handled.

Keep reading

Kenyan Compliance and Integrations

How to Integrate the M-Pesa Daraja API Into Your System

The Daraja API is Safaricom's official gateway to M-Pesa. This is the practical path from developer credentials to a live, reconciling integration - and the pitfalls along the way.

6 min readRead article →
Kenyan Compliance and Integrations

SHIF, NSSF and PAYE: Getting Kenyan Payroll Right

Kenyan payroll is a stack of statutory deductions - PAYE, SHIF, NSSF and the housing levy - each with its own rules. Getting the order and the remittances right is what keeps you compliant.

6 min readRead article →
Kenyan Compliance and Integrations

Securing Your Payment Integration: Webhooks, Secrets and Fraud

A payment integration is a door to your money. Attackers forge callbacks, replay requests and hunt for leaked keys. Here are the controls that keep the door shut.

7 min readRead article →