Pesa Laravel Package

Product Decisions This Supports

• Build vs. buy for the payments layer. The package is a thin, MIT-licensed abstraction over Tanzanian mobile-money APIs (M-Pesa, Tigo Pesa, Airtel Money, Halopesa). It gives you a concrete baseline to price the "build" option: if your team would otherwise spend 4–8 weeks writing per-operator auth, request signing, and payload mapping, that is the delta a buy/integrate decision is really comparing.
• Operator coverage on the roadmap. The wrapper's shape forces an explicit answer to "which wallets do we support at launch, and in what order?" — useful for prioritizing M-Pesa-first coverage versus a long tail of smaller wallets where volume does not justify integration effort.
• Unified vs. native checkout UX. Because it exposes a single calling convention across operators, it informs whether your product can promise one checkout flow with a provider picker, or whether you need operator-specific flows (USSD push prompts, PIN entry, timeout handling) that fragment the experience.
• Collections vs. disbursements scoping. Mobile-money products split cleanly into pull (checkout, subscriptions) and push (refunds, payouts, payroll, agent float). The package's surface tells you which of these is cheap to ship now and which needs its own design and reconciliation work.
• Adapter/anti-corruption layer as an architectural commitment. Adopting it is a decision to keep payment providers behind an internal interface, so a future swap to an aggregator (Selcom, ClickPesa, Flutterwave, Pesapal) is a config change rather than a rewrite.
• Reconciliation and finance-ops staffing. Any direct-to-operator integration implies you own settlement files, mismatch handling, and chargeback/refund support. That is a headcount and process decision, not just an engineering one — worth surfacing before commit.
• A roadmap "not now" signal. With 29 stars and a last release in March 2022, the honest PM read is that this is a reference implementation, not a maintained dependency. That supports a decision to de-risk rather than adopt: use it to sharpen estimates, then decide between forking it, wrapping it, or going to an aggregator.

When to Consider This Package

Consider it when:

• Your stack is PHP/Laravel and you need Tanzanian mobile-money acceptance with a plausible path to more than one wallet.
• You are in discovery or MVP and want a fast, low-cost way to validate that a payment flow works end-to-end before committing to a vendor contract.
• You want a reference implementation to brief engineering on request/response shapes, error taxonomies, and callback handling per operator.
• You can accept taking ownership of the code: fork it, pin it, add tests, and treat the upstream as a starting point rather than a source of updates.
• Your volume and risk profile are modest enough that a self-managed integration with basic retry and reconciliation is acceptable.

Look elsewhere when:

• You need an uptime or support SLA, security review evidence, or a vendor to escalate to during an incident. There is no such counterparty here.
• You require actively maintained code: PHP 8.2+/8.3 support, current framework compatibility, dependency hygiene, and a release cadence. The two-year-plus gap since the last release is a live risk.
• Your roadmap includes cards, bank transfer, or multi-country coverage — this is mobile money in one market, and adjacent rails mean a second integration anyway.
• You need production-grade idempotency, webhook verification, retry/backoff, and settlement reconciliation as first-class, tested features rather than something your team writes.
• You are operating at scale where an aggregator's commercial terms (single contract, consolidated settlement, negotiated fees) beat the per-operator integration and ops burden.
• Compliance or PCI-adjacent audit obligations mean unaudited, low-adoption third-party code is a non-starter in the payment path.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed PHP toolkit that lets our Laravel app talk to Tanzanian mobile-money wallets through one interface instead of four. The real value is in the decision it informs and the weeks it saves on discovery — it de-risks our estimate for a payments MVP and shows us exactly what "direct integration" costs us in ongoing engineering and finance-ops effort. I do not recommend it as a long-term dependency as-is: it was last released in early 2022 with a small user base, so there is no support line and no guarantee of framework compatibility. The recommendation is to use it as a reference and prototype accelerator, then make a deliberate call between (a) forking and owning a thin in-house wrapper, or (b) contracting an aggregator for consolidated coverage, settlement, and support. Budget for one engineer to own the payment path either way — that ownership cost exists in both options and should be in the plan, not a surprise.

To engineering: Treat it as a blueprint plus optional scaffolding. The abstraction boundary is the useful part — keep providers behind our own interface so swapping to an aggregator later is contained. Before any production traffic we need to add what a 2022-era library will not give us: idempotency keys, verified callbacks, retry with backoff, structured error mapping per operator, reconciliation against settlement files, and a pinned, tested fork with a documented upgrade path. Please return a short risk register with time-to-integrate estimates for each wallet so we can feed a real build-vs-buy comparison.