Laravel Pay Pocket Laravel Package

Product Decisions This Supports

• Build vs. buy for wallet/ledger functionality. Any roadmap item that needs per-user balances — stored value, prepaid credits, rewards points, affiliate earnings, escrow-style holds, or in-app currency — can be scoped against what this package already gives you: multiple named "pockets" per user, deposit/withdraw/transfer primitives, and a persisted transaction trail. That turns a multi-sprint "build a ledger" epic into a configuration and hardening task, which is the single most valuable decision this assessment informs.
• Feature sequencing. If the roadmap contains a payments-adjacent feature (tipping, refunds as store credit, referral payouts, subscription top-ups), this package lets you ship a v1 with explicit limits rather than blocking on a bespoke accounting service. It supports deciding what ships now versus what waits for a real double-entry system.
• Scope boundaries on "money." The package is a pocket/balance abstraction on top of your application database, not a payment processor and not a general ledger. It helps you draw the line between what the product promises (a user-visible balance and history) and what it must never promise without additional work (reconciliation guarantees, multi-currency handling, regulatory audit trails).
• Make vs. maintain cost. Vendor and namespace now sit under toneflix/laravel-pay-pocket at a 4.x line tracking Laravel 12/13. That is a signal the maintainer is actively keeping pace with the framework, which affects your long-term maintenance estimate for anything built on top of it.
• Migration/upgrade planning as a product risk item. The 4.0.0 rename is an unavoidable, code-touching break (Composer package name, PHP namespace, published config). If any shipped feature depends on the 3.x line, that is now a scheduled piece of work with a hard floor of PHP 8.3 and Laravel 12 — which is really a decision about your platform upgrade timeline, not the package's.

When to Consider This Package

Consider it when:

• You are on Laravel 12 or 13 and PHP 8.3+, or already committed to getting there. On 4.x there is no fallback for older runtimes; 3.x is the terminal branch for Laravel 10/11 estates.
• The product needs user-owned, named balances with movement between them — a natural fit for credits, wallets, reward buckets, or internal settlement between pockets.
• You want the transactional bookkeeping and history UI/API surface solved conventionally and are comfortable owning the business rules (limits, fees, approval flows, idempotency) in your own domain layer.
• You are building an early-stage or internal product where time-to-market outweighs the cost of eventually replacing a package-level ledger with a bespoke accounting model.
• You have a greenfield codebase, which makes the 4.0.0 namespace rename free — you simply start on the new namespace and never touch the old one.

Look elsewhere when:

• You need regulated money movement, multi-currency, FX, or reconciliation against a bank/payment provider. Use a real ledger or a payments provider's balance product; a package abstraction will not satisfy audit or compliance review.
• You require strict double-entry accounting, immutable append-only journals, or idempotent external settlement. Those are design commitments you should own end to end.
• You are locked to Laravel 10/11 or PHP below 8.3 — 4.0.0 will not install, and staying on 3.x means accepting an unmaintained line.
• Your team has a strong "no third-party dependency on the money path" policy. That is a legitimate stance and this package does not clear it.
• You need vendor-backed SLAs. This is a single-maintainer open-source package; the 4.0.0 vendor and namespace changes are a reminder that its identity is not contractually stable.

How to Pitch It (Stakeholders)

For executives — one paragraph. We evaluated toneflix/laravel-pay-pocket, a Laravel package that provides user wallets with named balances, transfers, and a transaction history. It is a genuine accelerator for balance-style features — store credit, rewards, referral earnings, prepaid top-ups — that would otherwise cost us a multi-sprint build. The new 4.0.0 release keeps it current with Laravel 12 and 13, which is a good sign of maintenance. Two caveats matter commercially: it is not a payment processor or an accounting system, so anything involving real regulated money still needs a proper provider; and 4.0.0 is a breaking release that renames the Composer package and PHP namespace and raises the floor to PHP 8.3 / Laravel 12, so adopting it now effectively ties this feature to our platform upgrade timeline.

For engineering — the practical summary.

• What it is: a pocket/wallet abstraction over your database. Multiple named balances per user, deposit/withdraw/transfer operations, transaction records. Business rules (fees, limits, approvals, concurrency and idempotency) remain ours to implement and test.
• What changed in 4.0.0: vendor rename toneflix-code/laravel-pay-pocket → toneflix/laravel-pay-pocket; namespace ToneflixCode\LaravelPayPocket → Toneflix\LaravelPayPocket; requires PHP ^8.3|^8.4 and Illuminate ^12.0|^13.0; dev tooling on Testbench 10.11/11.1 and Pest 4; README and CI matrix updated for Laravel 12/13.
• Upgrade mechanic: composer remove the old package, composer require toneflix/laravel-pay-pocket:^4.0, then rewrite imports and the published config namespace. It is a mechanical but global find-and-replace, plus a platform bump — cheap on greenfield, a scheduled ticket on an existing deployment.
• Recommendation: adopt on Laravel 12/13 projects where we need balances fast and can keep ledger-critical logic in our own service layer; do not adopt for regulated money movement, and do not adopt if we are stuck below PHP 8.3 — in that case treat 3.x as frozen and plan the platform upgrade before building on it.