← Back to blog10 April 2026

M-Pesa Daraja API for Kenyan businesses: STK Push, C2B, and what to plan before you build (2026)

A plain-language guide for Kenyan companies adding M-Pesa to websites and apps—Daraja rails, planning, and when to bring in developers.

If customers already ask whether they can pay via M-Pesa, you are past the “nice to have” stage. The next question is how you accept it—in a way that finance can reconcile, support can explain, and your product team can maintain. This article is for Kenyan business and product leaders who need orientation before committing engineering time or vendor spend.

This is not legal or financial advice. For API behaviour, fees, and compliance, rely on Safaricom’s official Daraja and developer documentation and your advisers.

What “Daraja” is (in one paragraph)

Daraja is Safaricom’s suite of APIs that let registered businesses integrate M-Pesa into digital channels. Your developers (or a partner like us) use these APIs to trigger payments, receive callbacks, and automate reconciliation—instead of manually checking SIM toolkit messages or spreadsheets.

The rails people confuse: STK Push vs C2B vs B2C

You do not need to memorize acronyms. You need to know which customer journey you are building.

Lipa na M-Pesa Online (often called STK Push)

Best when a customer is on your website or app and should approve a specific amount on their phone in real time. Typical use: checkout, invoice payment, booking fee. The user enters their phone number (or you use a saved number), gets a prompt, enters PIN, and you receive a result via callback.

Customer to Business (C2B)

Best when money is pushed to your paybill or till without you initiating the prompt from your server for every transaction—for example, customers paying via the M-Pesa menu using your paybill. You still integrate for validation and confirmation callbacks so your system knows who paid and for what.

Business to Customer (B2C)

Used when you send money out to customers or suppliers—refunds, payouts, incentives. This is a different risk and operations profile from collecting payments.

Many projects need more than one rail over time (for example, STK Push for web checkout plus C2B for “pay bill” habits). Planning beats bolting on a second path under pressure later.

What to decide before you write code

1. The customer journey

Where does the payer start—web, app, WhatsApp, invoice email?
What proof do they see after success (receipt, order status page)?
What happens on failure or timeout—retry, support path, duplicate payment handling?

2. Reconciliation

Finance will ask: How does a transaction in M-Pesa map to an order, invoice, or customer record? If you cannot answer that, you will create manual work at month-end.

3. Security basics

API keys and secrets belong on the server, not in mobile app bundles or browser JavaScript. Idempotency (safely retrying requests) matters for payment flows.

4. Sandbox vs production

You will test in sandbox first. Treat sandbox success as necessary but not sufficient—production behaviour, support escalations, and edge cases still need a runbook.

Websites vs mobile apps

Websites often pair STK Push with server-side confirmation and a clear post-payment page.
Apps may add device-specific UX, but the trust boundary for secrets remains server-side.

If you are deciding what to build first, we help teams align minimum viable payment flow with the rest of your roadmap.

When to involve a development partner

Bring developers in when you need callbacks, reconciliation, refunds logic, and operational tooling—not only a button that says “Pay with M-Pesa.” That is where integrations create durable value.