What Daraja 3.0 changed, and what it did not
The short version: your existing integration still works. The endpoints did not move, the OAuth flow did not change, and the callback payload has the same shape. The new surface is genuinely new, and sits beside the old one rather than replacing it.
If you only need one answer
Nothing in a working Daraja 2.0 integration needs to change. If something broke recently, Daraja 3.0 is unlikely to be why — start with the code reference and the reasons callbacks go missing.
What did not change
The useful half, and the half the launch coverage buried.
/mpesa/stkpush/v1/processrequest— same path./oauth/v1/generate, same base64-encoded key and secret, same OAuth2 client-credentials flow.- Same structure:
Body.stkCallbackwithMerchantRequestID,CheckoutRequestID,ResultCodeandCallbackMetadata. Your existing parser is fine. - Existing 2.0 integrations run unmodified on the 3.0 platform.
Source: developer reporting on the 3.0 platform, cross-checked against the request shapes in my own integrations, which are unchanged.
What is actually new
Added surface, not a migration. None of it is required to keep collecting payments.
- Recurring and scheduled payments on daily, weekly, monthly and yearly cycles. This is the genuinely significant one — Daraja 2.0 had no recurring-payment API at all, so every subscription product in Kenya built its own scheduler on top of one-off STK pushes.
- Fraud detection and identity verification.
- Payments initiated by connected devices.
- JavaScript apps running inside the M-Pesa Super App.
- A claimed ceiling of 12,000 transactions per second on a cloud-native, microservices architecture. Reported figure, not something an integrator can verify.
Source: launch reporting from November 2025 and developer write-ups since. Attributed as reporting — I have not built against Ratiba, and will not claim otherwise until I have.
The open question: is go-live really self-service now?
The claim I cannot yet confirm or refute.
The launch coverage says self-service onboarding has replaced the manual approval process — that you can go live without the back-and-forth with Safaricom’s integration team.
Safaricom’s own developer portal does not document this. I read it on 2026-10-21: it presents Daraja 3.0, describes creating an account and a sandbox app, and carries testimonials saying “going live is a smooth process”. There is no documented self-service approval flow, and no production-approval workflow described at all.
So the honest position is that this is a reported change rather than a documented one. My own account of the old process — nineteen days, none of them engineering — describes what it took before. Whether that is now hours depends on something I will only know from the next go-live I run.
This page will be updated with a first-hand account when I next take a client through production approval. Until then it reports the claim and the gap, rather than resolving it.
Still unresolved
What the upgrade did not fix.
- The sandbox still cannot simulate failure states. You cannot trigger insufficient funds or a cancelled transaction, which are the two paths most worth testing. This is why testing callbacks locally still matters, and why a community alternative appeared in early 2026.
- The portal now requires 2FA to read the documentation. Reported, and a real friction for anyone evaluating the API before committing to it.
- SDK support has not followed. No significant library updates for 3.0 beyond one C# package, as of this review.
How this page is sourced
Endpoint and payload claims are checked against my own running integrations. The new-API list and the capacity figure come from launch reporting and are labelled as such. The onboarding section records what Safaricom’s portal does and does not say, read on 2026-10-21. Where I have not done something myself, this page says so rather than implying experience it does not have.