Cashier Laravel Package

Product Decisions This Supports

• Paywall / subscription feature gating. The package's Billable-style helpers let you gate premium features behind a subscription record, which is the core enabler for a tiered pricing launch, free trials, or a "pro" upsell inside an existing Laravel app.
• Build vs. buy vs. fork. Because this is a subtree split of the Cashbox component (cashbox/foundation), adopting it is really a decision to adopt the upstream Cashbox ecosystem. That reframes the choice from "vendor a package" to "commit to a maintained-or-forked billing foundation," which is a roadmap-level commitment rather than a sprint-level convenience.
• Billing provider flexibility. Cashier-style packages exist to abstract the payment provider behind config-driven drivers. That supports a roadmap decision to keep Stripe/Paddle choice reversible for 6–12 months instead of hard-coding one vendor into the product.
• MVP / internal-tool scope. For a prototype, back-office tool, or a legacy Laravel app already on the Cashbox component, this is a low-ceremony way to stand up subscription state, webhook handling, and entitlement reads without building a billing layer.
• Maintenance-burden planning. The repo is archived (last release 2023-07-09, 9 stars, low adoption score). That is itself a product decision input: it forces an explicit choice between (a) treating it as vendored/forked code you own, (b) staying on the upstream cashbox/foundation package, or (c) migrating to the officially supported laravel/cashier.
• Risk/roadmap governance. Adopting an archived dependency sets a recurring "security patch + Laravel-version compatibility" line item on the roadmap. PMs should model that cost before greenlighting.

When to Consider This Package

Consider it when:

• You already depend on cashbox/foundation or the Cashbox ecosystem and want the split-out convenience package for a specific app.
• You are prototyping subscription flows and want expressive, framework-native helpers fast.
• You have engineering capacity to vendor/fork the code (MIT license permits it) and own patches, security reviews, and Laravel-version bumps yourself.
• The scope is internal, low-blast-radius, and does not touch real money movement at scale.

Look elsewhere when:

• You are building greenfield, customer-facing billing — an archived package with 9 stars and no maintainer is not a foundation for revenue-critical flows. Use the officially supported laravel/cashier (Stripe/Paddle) or a maintained alternative.
• You need guaranteed security patching, PCI/SCA-adjacent guarantees, or vendor support SLAs.
• You rely on modern Laravel/PHP versions released after mid-2023 — compatibility is unverified and will degrade over time.
• You need multi-provider support or plan to swap providers frequently; a low-adoption abstraction can become a liability rather than an asset.
• You cannot absorb the "fork and maintain" tax — the true cost is not integration, it is indefinite ownership.

Decision criteria to apply: upstream activity of cashbox/foundation, Laravel-version compatibility, size of the surface you'd need to fork, and whether the official Cashier covers the same use case (it usually does).

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel helper package for subscription/billing workflows. Integration is cheap and the API is familiar, but the repository is archived and barely adopted — it receives no updates or security fixes. We should treat it, at best, as a short-term or internal-only enabler, not as the billing foundation for revenue-critical product. Recommendation: use the officially supported Laravel Cashier for anything customer-facing, and only consider this package where an existing dependency already ties us to Cashbox and we accept owning the code.

For engineering: It is a subtree split of cashbox/foundation — service provider, facade, publishable config, Billable-style trait, webhook handling. Small surface, easy to read in an afternoon. The cost is durability: no release notes beyond changelog links, no maintainer, and unknown compatibility with recent Laravel. If we adopt it, we plan to vendor it, pin versions, add a recorded-webhook regression test, and schedule a review before the next framework upgrade.

Bottom line: Low integration cost, high long-term ownership cost. Approve a time-boxed spike only; default the roadmap to laravel/cashier for anything that touches customer money.