Mpesa Laravel Package

Product Decisions This Supports

• Market expansion into Kenya / East Africa: M-Pesa is the dominant payment rail in the region. This package is a candidate building block for the collection and disbursement primitives needed to support a first launch in that market — a gating dependency for a Kenya go-to-market, not a nice-to-have.
• Checkout / payments roadmap: Supports an STK Push (Lipa na M-Pesa Online) checkout flow, C2B collections, B2C payouts (refunds, seller/creator payouts, wage disbursements), and transaction status/reversal queries. These map directly to "accept payments locally" and "pay out locally" epics.
• Build vs. buy vs. borrow: The real decision is between (a) adopting this package as-is, (b) forking/vendoring it as a reference spec and writing a thin internal wrapper, and (c) buying a fully managed payment orchestration layer that abstracts M-Pesa among other rails. This package mainly informs (a) vs. (b). Release 1.0.8 (.env parameter parsing) nudges the estimate on option (b) down slightly — it removes a small amount of config-ripping work from the fork — but does not change the shape of the decision.
• Vendor/partner integrations: If the product needs to sit behind or in front of another M-Pesa paybill/till (marketplaces, aggregators, B2B2C platforms), the request/response shapes here define the contract you'll be negotiating.
• Prioritization signal: Its 2019 release lineage and near-zero ecosystem adoption mean it should not be treated as a product dependency with a maintenance SLA — it should be scoped as a research spike or a vendored reference, which changes the estimate and the risk register entry. A 1.0.8 patch that only adds .env parsing is a signal of low but nonzero upstream activity, not a signal of renewed investment; do not upgrade your confidence in its long-term support based on it.

When to Consider This Package

Consider it when:

• Your stack is PHP/Laravel and you need a fast, low-commitment spike to validate Daraja API behavior (auth, STK Push payloads, callback shapes) before committing to a design.
• You only need a narrow, well-understood surface — e.g., STK Push for a single paybill — and you're prepared to vendor the code and own it.
• You want an authoritative-looking reference for request signing (password = base64(shortcode + passkey + timestamp)), security credentials, and endpoint paths, because it lives under the Safaricom GitHub org.
• You want credentials kept out of source control from day one — 1.0.8's .env parameter parsing means sandbox keys, shortcodes, and passkeys can be swapped per environment without editing files. This is a genuine convenience for spikes and local/sandbox work.
• You're prototyping in sandbox and speed matters more than longevity.

Look elsewhere (or budget to fork) when:

• You need a maintained dependency. The core of the library dates to January 2019; Daraja has moved on (v1 → v2 endpoint changes, deprecated paths, updated credential handling). The 1.0.8 .env patch is a convenience fix, not a modernization — the endpoint and payload assumptions are still vintage-2019. Expect breakage in production and no reliable upstream fixes.
• You need production-grade concerns the package likely doesn't solve: callback authenticity validation, idempotency keys, retry/backoff on timeouts, reconciliation against the M-Pesa statement/transaction status API, queue-based async handling, and Laravel-native config/events. Note on 1.0.8: .env parsing is configuration, not secrets management — it is not the same as a Laravel service provider with publishable config, encrypted secrets, environment-aware validation, or key rotation. Treat the gap as narrow-but-real: the "can I configure it per environment" objection is now largely retired; the "is it safe to hold live merchant credentials" objection is not.
• You need multi-tenant or multi-shortcode support, or per-merchant credential isolation. .env is a single global environment — it works against you here, since multi-tenant credential isolation is the opposite of process-wide env vars.
• Your stack isn't PHP, or you need a vendor with an SLA, support contract, or SOC/compliance attestations.
• You're doing high-volume B2C or marketplace split payouts where reconciliation accuracy and ledgering are the hard part — this package covers the HTTP call, not the money movement semantics.
• Regulatory posture matters: Kenya's Data Protection Act and CBK payment-service rules put obligations on you (PII handling, audit trails, dispute handling) that no 2019-era SDK addresses. Loading credentials from .env does not constitute an audit trail or a control.

Decision heuristic: treat it as documentation with executable examples, not as a dependency. If a maintained community SDK or a managed provider is available, compare total cost of ownership — a weekend fork is now marginally cheaper than before 1.0.8, but an unmaintained critical-path payment dependency is still not cheap. The heuristic is unchanged.

How to Pitch It (Stakeholders)

To executives: M-Pesa is the payment rail we need to enter Kenya, and this is Safaricom's own PHP SDK — which buys us credibility and a head start, but not a product. Its recent 1.0.8 release is a small developer-convenience fix (reading credentials from environment files); it is not a sign that the SDK is being actively invested in or supported. My recommendation is unchanged: use it as a spec and starting point and budget roughly [X engineer-weeks] to harden or wrap it before it touches real money — the latest release shaves a little off that estimate, not the risk. That's still far cheaper than building the integration from zero, and it de-risks the market-entry timeline. The decision I need is whether to fund that hardening work now, or defer Kenya until we've chosen a managed payments provider that includes M-Pesa.

To engineering: This gives us the Daraja request/response shapes and the tricky bits — password/security-credential generation, STK Push, C2B, B2C, status queries — for free, and as of 1.0.8 it will read config from .env instead of requiring hardcoded credentials, so sandbox setup is quicker. It still does not give us callback verification, idempotency, retries, reconciliation, a secrets-management story beyond plain env vars, or a Laravel service provider. Plan to vendor it, pin it, wire it into Laravel's own config/ rather than leaning on its env parser, wrap it behind our own MpesaClient interface, and write tests against sandbox. Assume no upstream patches beyond cosmetic ones; anything we need, we own.

To finance/legal: Any integration we ship becomes a money-movement path, which brings reconciliation, dispute handling, and Kenya DPA/CBK obligations into scope. Those are ours to satisfy regardless of which SDK we pick; this package provides no compliance surface — and moving credentials into a .env file is a hygiene improvement, not a control or an audit trail. Don't let "Safaricom publishes it" read as "Safaricom warrants it."