M-Pesa (Daraja)
Connect M-Pesa (Daraja) to the rest of your business, with the right person approving what changes and a record of every action.
4 ways to read, 6 ways to write, each write switched on by you.
Quality checks
Built and tested with example responses.
- Ready to connect: doneEvery listed action is built in.
- Built and tested with example responses: doneEach action is built from the provider’s published API and tested against example responses, errors, rate limits and paging.
Connected, approved, proven.
The things teams do most with M-Pesa (Daraja), an example flow with a person in the loop, and what Nexra keeps as proof.
Top actions
- Pay another business
b2b_transfers.createApproval by rule - Send money to a customer
b2c_payouts.createApproval by rule - Check account balances
balance_checks.searchRead
Example flow
- M-Pesa (Daraja) · Check account balances
balance_checks.searchDone - M-Pesa (Daraja) · Pay another business
b2b_transfers.createMaker-checker - Nexra · Record the decision and result in the evidence chainProven
Example workflow. Routine runs go through on their own. Only a change your rules flag, such as one over a limit you set, waits for the right person, who sees the exact change and the rule before it reaches M-Pesa (Daraja).
What gets logged
- Whether it ran on its own or who approved it, and under which rule
- A fingerprint of the exact request sent to M-Pesa (Daraja)
- M-Pesa (Daraja)'s reply: what it created or changed
- One entry in the evidence chain, linked to the one before
Try this in the sandbox
Run the whole flow with test data in your sandbox, then connect a Safaricom test account before you go live.
For developers
Technical detail
Safaricom M-Pesa Daraja: payment prompts (STK push), customer payment notifications and history, transaction status and balance checks; governed customer payouts, business payments and reversals.
Safaricom API docs- Source actions
- 4
- Destination actions
- 6
- Data types
- 9
What you can map
Reads are always available. Writes are off until you switch them on for a connection, and governed writes follow your policies.
b2b transfers1
- Pay another businessDestinationNot retried automaticallyApproval before production
Pays a paybill or till from your M-Pesa account (Business PayBill or Business Buy Goods). Moves money: governed exactly like other transfers.
b2c payouts1
- Send money to a customerDestinationNot retried automaticallyApproval before production
Pays an M-Pesa customer from your B2C account (salary, business or promotion payment). Moves money: governed exactly like other payouts.
balance checks1
- Check account balancesSource
Asks M-Pesa for your account balances. The answer arrives at your M-Pesa trigger.
c2b notification urls1
- Send customer payments to NexraDestinationProvider duplicate protectionApproval before production
Tells M-Pesa to send every payment to your paybill or till to your M-Pesa trigger in Nexra. In Live mode this can be done once; changing it later needs Safaricom's URL Management.
c2b transactions1
- List customer paymentsSourceIncremental
Payments customers made to your paybill or till in the last 48 hours (Pull Transactions), for matching to your ledger.
payment prompts2
- Send a payment promptDestinationNot retried automaticallyApproval before production
Sends an M-Pesa payment prompt (STK push) to the customer's phone. Money moves only when the customer enters their M-Pesa PIN.
- Get payment prompt statusSource
Whether the customer approved, cancelled or ignored an M-Pesa payment prompt.
pull registrations1
- Register for customer payment historyDestinationProvider duplicate protectionApproval before production
One-time registration so Nexra can list the last 48 hours of customer payments for reconciliation (Pull Transactions).
reversal refunds1
- Reverse a customer paymentDestinationNot retried automaticallyApproval before production
Reverses a customer payment (C2B or payment prompt) back to the customer. Moves money: governed exactly like other refunds.
transaction status checks1
- Check a transaction's statusSource
Asks M-Pesa for the status of a transaction by its receipt or request ID. The answer arrives at your M-Pesa trigger.
Access and limits
- Authentication
- Daraja consumer key and secret
- Plans and access
- A Daraja app on developer.safaricom.co.ke; live use needs a live paybill, till or B2C short code taken through Go Live. Payouts, business payments, reversals, status and balance checks need an API operator (initiator) with the matching role in the M-Pesa business portal.
- Test environment
- Create an app on the Daraja portal; the sandbox uses Safaricom's test short code 174379, its published passkey and test numbers, and moves no real money.
- Rate limits
- Safaricom does not publish numbers; it refuses bursts with 500.003.02 (spike arrest) and quotas with 500.003.03. Each new access token replaces the previous one, so Nexra keeps one per connection.
- Pagination
- Customer payment history pages with OffSetValue; every other call returns one result.
- Provider events
- M-Pesa posts payment prompt results, customer payment confirmations and the results of payouts, transfers, reversals, status and balance checks to the addresses you give it. Callbacks are not signed and are not retried. Flows can start the moment something happens: when a customer pays your paybill or till; when a customer answers a payment prompt; when a payout, transfer, reversal, status or balance result arrives.
Before you build a flow
- Money movement is customer-governed: customer payouts (B2C), business payments (B2B) and reversals are the highest risk tier and are refused until money movement is switched on for the workspace and the action, with approvals and limits.
- Payment prompts ask the customer to approve on their phone; nothing moves without their PIN.
- Payouts and settlements: M-Pesa has no settlement read; payout results arrive at your M-Pesa trigger.
- Refunds: refunds are made as reversals of customer payments; their results arrive at your M-Pesa trigger.
- Disputes: M-Pesa publishes no dispute API.
- Fees: M-Pesa reports charges only inside payout and status results at your trigger, not on customer payment history.
- Payouts, transfers, reversals, status and balance checks are answered later at your trigger address, not in the response. Nexra never repeats an uncertain request: check the transaction status first.
- Customer payment history (Pull Transactions) covers the last 48 hours and needs a one-time registration; payment notifications at your trigger cover everything after that.
- Callbacks are not signed: the trigger address carries a private key, and payments should be confirmed with a status check before booking. Safaricom's callback IP addresses are listed in its Getting Started guide.
- Customer phone numbers are masked; names in callbacks are not passed to flows.
Developer reference
- Create the Safaricom credentials described above with the narrowest permissions your flows need.
- In Nexra, open Connect, then Connections, then New connection, choose M-Pesa (Daraja), enter its settings and credentials, and tick only the write actions you need. Connection guide
- Test the connection, then use its actions as flow sources and destinations. Flow guide
Machine-readable detail: GET /api/public/connect/connectors/mpesa-daraja and the Connections API.