Laravel Mesomb Laravel Package

Product Decisions This Supports

• Payment collection & disbursement in francophone Africa (MTN MoMo, Orange Money): the package wraps MeSomb's mobile-money APIs so the team can ship checkout, collection, and payout flows without building direct telco integrations.
• Build vs. buy: the decision is now "buy the official integration, not this wrapper." MeSomb's own team publishes and maintains hachther/laravel-mesomb, which this package explicitly redirects to as of 1.6.
• Roadmap impact — migration work item: 1.6 is the final release. Any roadmap item depending on this package (new payment method, multi-currency, refunds, webhook handling) should be re-scoped against the official package, not this one.
• Tech-debt / exit-strategy decision: treat this dependency as end-of-life. Plan a swap before the next Laravel or PHP major upgrade, since no compatibility fixes will arrive.
• Vendor-risk decision: because the maintainer has handed support to the MeSomb team, long-term continuity of the integration is fine — the continuity risk is with this specific package name, not with the payment capability.
• Pricing/margin and ops decisions (fees per transaction, reconciliation, payout timing) remain unaffected — this is a packaging change, not a capability change.

When to Consider This Package

Consider only as an existing/legacy dependency:

• You already ship it in production and need a short, low-risk window before migrating.
• You are on a Laravel/PHP version the package already supports and are not upgrading soon.

Look elsewhere — specifically at hachther/laravel-mesomb — if:

• You are starting new work. Do not adopt an EOL package; the maintainer and MeSomb both point to the official one.
• You need ongoing bug fixes, security patches, or support for new Laravel/PHP releases.
• You need newer MeSomb API features (additional payment operators, updated webhook/payment-status semantics) — these will land in the official package only.
• You require vendor-backed support, SLAs, or a documented upgrade path for compliance/audit reasons.

Migration criteria to weigh: API surface differences (config keys, facades, DTOs, exception types), webhook signature/route changes, and whether stored transaction references remain valid. Budget a small spike to diff the two APIs before committing a sprint.

How to Pitch It (Stakeholders)

For executives: The payment integration we use for mobile-money collections in Cameroon is being retired by its maintainer. The good news is that MeSomb itself now ships and supports an official Laravel package, so the payment capability is more durable than before — we just need to move our code onto it. This is a maintenance swap, not a re-platforming: no product features change, no customer-facing impact expected, and it removes the risk of being stuck on an unsupported dependency. Recommendation: approve a small, time-boxed migration sprint ahead of our next framework upgrade, before the old package silently becomes a blocker.

For engineering: Release 1.6 is explicitly the last release and redirects to hachther/laravel-mesomb, maintained by the MeSomb team. Freeze feature work on the current wrapper, pin the version, and schedule the migration. Start by diffing config, facade/API call sites, exception handling, and webhook routes between the two packages; then migrate behind the existing payment abstraction so the swap stays contained. Flag any place we depend on internals rather than the public API — those are the real cost drivers. Add the migration as a tracked tech-debt item with an owner and a deadline tied to our next Laravel/PHP upgrade.