Laravel Pay Pocket Laravel Package

Product Decisions This Supports

• Build vs. buy for balance/ledger functionality. A wallet-style package lets you ship credits, refunds, top-ups, and multi-account balances without owning ledger correctness work. The 4.0 release is a maintenance-and-compatibility signal, not a feature expansion — factor that into the build-vs-buy math: you are buying a head start, not a roadmap.
• Platform upgrade sequencing. 4.0 requires Laravel 12 or 13 and PHP 8.3+, and 4.0 is the only line supporting Laravel 13. If Laravel 13 is on your roadmap, this package is now a gating dependency — its upgrade must be scheduled with, or ahead of, your framework upgrade. Conversely, if you are pinned to Laravel 10/11, you are now on an unsupported branch and should treat this as a forcing function for a platform decision.
• Dependency and vendor-risk policy. The move from toneflix-code/laravel-pay-pocket to toneflix/laravel-pay-pocket — with a full namespace change — is a namespace-churn event. It is a legitimate, well-executed rename (major version, documented upgrade path), but for a PM it is evidence that this dependency's identity is still settling. That informs whether you allow it in payment-adjacent code paths, and whether you require an internal fork or wrapper interface.
• Where the money logic lives. Because the rename touches every use statement and the published config, it surfaces how deeply the package is embedded. If migration is trivial, your abstraction boundary is healthy; if it is painful, that is a signal to introduce a domain interface now, before the next rename.
• Scope decisions you should not expect it to answer. Pricing experiments, revenue recognition, and financial reporting generally sit outside a package like this; treat any such expectation as a build/integrate decision rather than a reason to adopt.

When to Consider This Package

Consider it when:

• You are on Laravel 12 or 13 with PHP 8.3+, or upgrading imminently, and 4.0 is a clean fit against your support matrix.
• You need application-level balances — user credits, top-up wallets, refunds, simple transfers — where a transaction record plus a balance is sufficient, and you do not need a full double-entry general ledger.
• Your team is small and would rather adopt a maintained starting point than design ledger semantics from scratch.
• You are willing to own the upgrade: pin to ^4.0, run the two-step Composer swap, and keep the namespace change in a single PR.
• You can absorb the fork risk — i.e., the codebase is small enough that "we maintain it ourselves if the maintainer stops" is a credible fallback.

Look elsewhere when:

• You are on Laravel ≤11 or PHP <8.3 and cannot move. There is no supported path forward on this line; stay pinned and plan, or choose a different dependency.
• You need audit-grade double-entry accounting, reconciliation, multi-currency FX, or settlement reporting — that is a domain-modeling problem a convenience package will not solve, and retrofitting it later is expensive.
• You operate under financial regulatory obligations (money transmission, PCI scope, KYC/AML) — the compliance surface must be designed, not inherited.
• You require vendor stability commitments — SLAs, long-term support guarantees, or a second rename is unacceptable. The rename itself is a reasonable event; the question is whether your risk tolerance matches a single-maintainer package in a money-adjacent path.
• Your throughput is high-write with strict consistency needs, where you would be tuning or replacing the package's persistence layer anyway.

Migration note for planning: the upgrade is mechanical but wide — composer remove toneflix-code/laravel-pay-pocket, composer require toneflix/laravel-pay-pocket:^4.0, then update all imports and the published config namespace. Budget it as a low-effort, cross-cutting change: hours of work, but it touches every file that references the package and must be sequenced with the Laravel/PHP bump, not after it.

How to Pitch It (Stakeholders)

For executives: This is a routine major-version release of a wallet/balance library — a rename and a framework-support bump, not a new capability. The decision it forces is a scheduling one: adopting 4.0 commits us to Laravel 12/13 and PHP 8.3+, which we likely want anyway. Cost is small and mechanical; the real consideration is that this is a small, single-maintainer dependency sitting near money-handling logic, so we should treat it as a component we are prepared to own rather than a vendor relationship. Recommendation: upgrade on our platform-upgrade timeline, wrap it behind an internal interface so a future rename is a one-file change, and keep the option to fork.

For engineering: 4.0.0 is a breaking release with a clean upgrade path: vendor and namespace move from toneflix-code/laravel-pay-pocket / ToneflixCode\LaravelPayPocket to toneflix/laravel-pay-pocket / Toneflix\LaravelPayPocket. Constraints tighten to PHP ^8.3|^8.4 and Illuminate ^12.0|^13.0; dev tooling moves to Testbench ^10.11|^11.1 and Pest ^4, with CI covering Laravel 12 and 13. The rename is a find-and-replace across imports plus the published config — low risk, high blast radius, so do it in an isolated PR with the Composer swap and expect no behavioral changes. Two things to watch: we lose the ability to patch against Laravel ≤11, and we should avoid letting the package's namespace leak into domain code — put an adapter in front of it now, while the migration is already forcing us to touch every call site.