Laravel Daraja Laravel Package

Product Decisions This Supports

• Build vs. buy for M-Pesa integration. This package is the cheap third option between "write our own Daraja client" and "buy a payments orchestrator." It gives you STK Push, C2B, B2C, transaction status and reversal calls behind a Laravel-native API, so the engineering question shifts from "how do we integrate Daraja?" to "do we need a paid orchestrator on top?"
• Market expansion into Kenya / East Africa. If mobile money is a launch requirement for a new region, this package materially shortens the time between "market approved" and "first successful STK Push in staging." That is a roadmap-date decision, not just an engineering one.
• Roadmap sequencing for Laravel upgrades. The v5.2.0 release makes this package installable on Guzzle 8, which unblocks apps already on the newer HTTP client (Laravel 13-era stacks). If a platform-upgrade epic is on the roadmap, this package is no longer a blocker for it — previously the Composer resolver would simply refuse. Applications on Guzzle 7 are unaffected and need no action.
• Risk and compliance posture. The project now routes vulnerability reports to a role-based [email protected] address and publishes SECURITY.md as the single authority, with README and CONTRIBUTING.md aligned. For a package sitting in your payment path, that is a concrete, checkable signal about how disclosed vulnerabilities get handled — useful evidence for a security review or vendor questionnaire.
• Documentation and onboarding cost. Docs now live at laraveldaraja.com with redirects from the old GitHub Pages URLs. If you have internal runbooks or onboarding docs pointing at the old links, they still work, so no cleanup sprint is required — but new documentation should cite the new domain.
• Vendor/partner integration scoping. Use cases this typically serves: checkout via STK Push, paybill/till collections, disbursements and refunds via B2C, and reconciliation jobs polling transaction status. Each of those maps to a distinct product surface you may or may not want to ship in a given quarter.

When to Consider This Package

Adopt it when all of the following hold:

• You are on a supported Laravel version and PHP 8.3 or 8.4 — CI covers Guzzle 7 on Laravel 12 and Guzzle 8 on Laravel 13, so both paths are tested rather than assumed. Do not take a README claim as a substitute for checking your own matrix.
• You already hold (or are actively obtaining) Safaricom Daraja credentials — consumer key/secret, passkey, shortcode, and the go-live approval for your paybill or till. The package does not grant you access to M-Pesa. It is a client, not a provider; the commercial and approval work with Safaricom happens outside it and is usually the real critical path.
• You want the Daraja calls wired into Laravel conventions — config, facades/services, HTTP client, callbacks — rather than a general-purpose PHP SDK.
• You are comfortable owning the payment-adjacent concerns the package does not solve for you: idempotency keys, callback endpoint hardening and replay protection, reconciliation against Safaricom statements, retry and timeout policy, and dispute handling.

Look elsewhere — or plan to build on top — when:

• You need multi-provider routing (M-Pesa plus cards, Airtel Money, MTN, Flutterwave, Stripe), unified settlement reporting, or a single reconciliation ledger across rails. That is orchestrator territory; this package is deliberately single-rail.
• You need the vendor to carry PCI-style assurances, uptime SLAs, or indemnities. This is a community open-source package, and adopting it means accepting the maintenance risk of a small-team project on your critical payment path.
• Your compliance team requires a formal support contract, named security response times, or a signed DPA. A SECURITY.md and a role-based inbox are good hygiene, not a contract.
• You are not on Laravel, or you need Daraja features the package does not wrap — verify coverage against your actual API surface before committing.

Migration note: upgrading from v5.1.0 is low-risk. Nothing in the package's behavior changed in v5.2.0 — the Guzzle constraint widened from ^7.8 to ^7.8 || ^8.0. Treat it as a compatibility release, not a feature release, and do not let it absorb a planning slot.

How to Pitch It (Stakeholders)

For executives: This is a free, open-source Laravel integration for Safaricom's M-Pesa API. The latest release is a compatibility and housekeeping update — it lets the package run on the newer Guzzle HTTP client, which removes a blocker for teams upgrading their Laravel stack, and it moves security reporting to a company-wide address with a published policy. There are no breaking changes and no new features. The strategic value is speed-to-market in Kenya: it turns M-Pesa from a bespoke integration project into a bounded configuration task. The caveats worth stating plainly are that it does not provide M-Pesa access — Safaricom onboarding remains on the critical path — and that it is community-maintained, so we own the operational risk on the payment path.

For engineering: v5.2.0 widens the Guzzle requirement to ^7.8 || ^8.0. Package code is unchanged; this only relaxes what Composer will accept, so apps on Guzzle 7 need to do nothing and apps on Guzzle 8 can now install. CI covers both — Laravel 12 with Guzzle 7 and Laravel 13 with Guzzle 8, on PHP 8.3 and 8.4 — so the compatibility claim is tested, not asserted. Security reports now go to [email protected], with SECURITY.md as the authoritative source and README/CONTRIBUTING aligned to it. Docs moved to laraveldaraja.com; old starnerz.github.io/daraja-docs/ links redirect, so no bookmark or runbook cleanup is urgent, but update internal references opportunistically. Before adopting, validate the wrapped API surface against our specific flows (STK Push, C2B, B2C, status, reversal) and confirm our idempotency, callback verification, and reconciliation layers sit outside the package, because they do. Pin the version and budget for the possibility that a small maintainer team goes quiet.