M-Pesa Gateway for Magento 2

Key Features

STK push checkout — shopper enters their Safaricom number and approves the M-Pesa PIN prompt on their phone via the Daraja `STK Push (Lipa Na M-Pesa Online)` API

C2B payment confirmation through a dedicated callback controller that validates the M-Pesa receipt, amount and shortcode before trusting it

Callback-driven order auto-confirmation: order stays in `pending_payment`, then moves to `processing` and invoices on a verified M-Pesa callback via an observer/service-contract flow

Sandbox + production Daraja support with a one-toggle environment switch in admin (consumer key/secret, passkey, shortcode, initiator)

KES settlement aligned to your Magento currency and multi-website store views

Proper Magento 2 payment method implementing `MethodInterface`, registered in `payment.xml`/`config.xml`

Admin configuration via `system.xml` under Stores > Configuration > Payment Methods, with ACL-gated access and encrypted credential storage

Cron-based reconciliation that re-queries the `STK Push Query` endpoint for requests that timed out or never returned a callback

Idempotent callback handling so Safaricom retries never double-confirm or double-invoice an order

Configurable order status mapping, debug logging to `var/log`, and a status timeline on the order admin grid

Optional GraphQL & REST API extension for headless / PWA Studio / mobile-app checkouts

Compatible with Magento Open Source and Adobe Commerce 2.4.x; coexists cleanly with other payment methods at checkout

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Magento 2.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

M-Pesa is how East Africa pays — but Magento Open Source and Adobe Commerce ship no native M-Pesa method, and generic Marketplace extensions rarely match a store's real checkout, multi-store or fulfilment flow. ECOSIRE builds this gateway to order: a proper Magento 2 payment module under app/code/Ecosire/MpesaGateway, wired the way Magento expects.

At checkout the shopper enters their Safaricom number and we trigger an STK push through the Safaricom Daraja API — the M-Pesa PIN prompt appears on their phone, they confirm, and money moves. Your store holds the order in pending_payment until M-Pesa calls back. Our C2B / STK callback controller (CSRF-exempt, signature- and amount-validated) receives the confirmation, matches it to the quote, and an observer / service-contract flow moves the order to processing and emails the customer — no manual reconciliation.

The build follows Magento conventions end to end: a Magento\Payment\Model\MethodInterface implementation, payment.xml + config.xml defaults, di.xml virtual types, admin system.xml configuration with ACL (consumer key/secret, passkey, shortcode, sandbox vs production), a cron job to reconcile timed-out STK requests, and encrypted credential storage. We expose payment status to your storefront and can extend the GraphQL and REST APIs for headless / PWA Studio builds.

Because it is built to order, it fits your store: your Magento version (2.4.x), your theme's checkout, your multi-website KES setup, your tax and invoicing rules. ECOSIRE installs it on staging, tests the full sandbox-to-live Daraja cutover with you, then deploys to production. You get the source, a short runbook and ongoing support. Honest delivery: this is not an instant download — typical lead time is 5–10 business days depending on customisation.

What you get

A Magento 2 module (`Ecosire_MpesaGateway`) delivered as source under `app/code` plus a Composer-installable package

Full Daraja integration: STK push, STK query, C2B confirmation and validation callbacks

Admin configuration section with ACL, encrypted credentials and sandbox/production switch

Installation on your staging environment plus guided sandbox-to-production Daraja cutover

A short admin + operations runbook (credential setup, going live, reading logs, reconciliation)

30 days of post-deployment support and bug fixes, with optional ongoing support thereafter

Compatibility validation against your specific Magento/Adobe Commerce version and checkout theme

Source code ownership so your team or any developer can maintain or extend it later

Who this is for

Kenyan eCommerce merchant on Magento 2

Runs a Magento Open Source store selling to Kenyan customers and needs M-Pesa at checkout because cards have low penetration. Wants STK push and automatic order confirmation without manual reconciliation.

East-African retailer scaling regionally

Operates multi-website Magento across Kenya, Tanzania and Uganda. Needs KES settlement, a clean sandbox-to-live path and a gateway that respects per-store-view configuration and existing fulfilment rules.

Adobe Commerce / agency dev team

A solution integrator or in-house team that wants a properly architected M-Pesa module (di.xml, service contracts, ACL, cron, GraphQL-ready) they can own and extend, rather than a black-box Marketplace extension that fights their headless or PWA build.

How M-Pesa Gateway for Magento 2 Compares

Criterion	ECOSIRE	Custom Build	Competitor
Native M-Pesa STK push payment method at checkout	Included	Partial support	Included
Built and tested for YOUR Magento version, theme and multi-store setup	Included	Included	Not included
Callback-validated automatic order confirmation (receipt + amount + idempotency)	Included	Partial support	Partial support
Cron reconciliation for timed-out / missing STK callbacks	Included	Partial support	Partial support
Proper Magento architecture (di.xml, service contracts, ACL, encrypted credentials)	Included	Partial support	Partial support
GraphQL / REST extension for headless / PWA Studio	Included	Partial support	Not included
Installed, sandbox-to-production cutover and supported by the vendor	Included	Not included	Not included
Source code ownership so any developer can maintain it	Included	Included	Partial support

Frequently Asked Questions about M-Pesa Gateway for Magento 2

How long until the M-Pesa gateway is live on my store?

Typical lead time is 5–10 business days from when we receive your Magento version, theme details and Daraja sandbox credentials. We build and test on staging first, run the sandbox-to-production cutover with you, then deploy to live. This is a build-to-order service, not an instant download — if your checkout is heavily customised or you need GraphQL/headless support, we'll confirm the timeline up front.

Do I get ongoing support and updates after launch?

Yes. Every build includes 30 days of post-deployment support and bug fixes. After that, you can take an optional ongoing support plan covering Magento 2.4.x upgrades, Daraja API changes from Safaricom, and enhancements. Because you receive the full source and own it, your own team or any Magento developer can also maintain it independently.

What do I need from Safaricom to use this?

You need a Safaricom Daraja developer account and a Lipa Na M-Pesa Online / Paybill or Till (shortcode) with its consumer key, consumer secret and passkey. We start on the Daraja sandbox for end-to-end testing, then switch to your production credentials. We'll guide you through requesting and configuring everything.

Will it work with Adobe Commerce and a headless / PWA Studio storefront?

Yes. The module targets both Magento Open Source and Adobe Commerce 2.4.x. The default build works with the standard Luma/native checkout; for headless, PWA Studio or a custom frontend we extend the GraphQL and REST APIs so STK push and payment status are available to your storefront. Tell us your stack and we'll scope it.

How does the order get confirmed after the customer pays?

When the shopper approves the STK push, M-Pesa sends an asynchronous callback to a dedicated, CSRF-exempt controller in the module. We validate the receipt number, amount and shortcode, match it to the Magento quote, and — only on a verified callback — move the order to `processing` and create the invoice. Callbacks are handled idempotently, and a cron job reconciles any STK request that timed out without a callback, so orders never get stuck or double-confirmed.