Laravel Pesa Laravel Package

Product Decisions This Supports

• Build vs. buy (integrate vs. build): Confirms whether to adopt an existing Laravel-native abstraction over Tanzanian mobile-money APIs (M-Pesa/Tigo Pesa/Airtel Money via OpenPesa) rather than building and maintaining provider integrations in-house.
• Platform/roadmap compatibility: v1.0.2’s added Laravel 9 and PHP 8.1 support signals the package can be carried into a modernized stack — useful input for upgrade planning and deciding whether payments work blocks or unblocks a framework upgrade.
• Release-readiness and risk posture: The shift to Pest, PHPStan, PHP CS Fixer, and expanded GitHub Actions indicates maturing engineering hygiene. This informs a “trust but verify” decision for production payment flows, where correctness and maintainability matter more than feature breadth.
• Scope clarity for roadmap: The release is explicitly a stability/CI release plus a command removal — no new payment features. PMs should not plan roadmap items (e.g., new providers, refunds, reconciliation) on the assumption this release delivers them.
• Pilot/MVP feasibility: Updated demo repo and supported-version matrix reduce time-to-first-transaction for a proof of concept, supporting decisions to trial the package in a limited market or low-volume flow before committing.

When to Consider This Package

Consider adoption when:

• You are building on Laravel 9 / PHP 8.1+ (or planning to upgrade) and want a framework-idiomatic wrapper rather than raw HTTP clients against each telco API.
• Your product needs Tanzanian mobile-money collection/disbursement via OpenPesa and you value reducing bespoke integration surface area.
• You want static analysis and automated test signals (PHPStan, Pest, CI) as a proxy for maintainability — relevant for payment-critical paths.
• You are validating a market entry or MVP where speed to a working payment flow outweighs deep provider-specific customization.

Look elsewhere or proceed with caution when:

• You require guaranteed enterprise SLAs, vendor support contracts, or audited compliance certifications — this is a community package with no such commitments in the release notes.
• Your stack is on older Laravel/PHP versions not covered, or on a framework other than Laravel.
• You need multi-country or multi-provider abstraction beyond OpenPesa’s coverage, or features like subscriptions, complex routing, or dispute handling not evidenced here.
• The removal of the command in this release affects any operational scripts or scheduled jobs you depend on — verify before upgrading.
• You need a stable, long-lived API surface: v1.0.x with a command removed in a patch-level release suggests the public surface is still settling.

How to Pitch It (Stakeholders)

For executives: This package lets our Laravel team accept mobile-money payments in Tanzania through an existing, maintained integration instead of building one from scratch — shortening time-to-market and reducing engineering overhead. The latest release is a stability and tooling update: it adds support for current Laravel and PHP versions and strengthens automated testing and code-quality checks. It does not add new payment capabilities, and it is a community-maintained dependency without a commercial support contract, so we should pair adoption with our own integration tests and a fallback plan.

For engineering: v1.0.2 brings Laravel 9 and PHP 8.1 support, adopts Pest, PHPStan, and PHP CS Fixer, and expands GitHub Actions — a meaningful improvement in code-health signals. Note two things before upgrading: a command was removed (audit for any scheduler or script dependencies), and the release is explicitly stability-focused, so treat the public API as still maturing. Recommended path: pin the version, run our own contract tests against sandbox credentials using the updated demo repo, and wrap the package behind an internal payment interface so we can swap providers if needed.