Core Laravel Package

Product Decisions This Supports

• Build vs. buy for billing: cashier-provider/core supplies the provider-agnostic billing domain (plans/prices, subscriptions, trials, proration, invoices, payment methods, webhook-to-event plumbing) as a Laravel package. Adopting it converts "build a subscription state machine" into "configure a package and write a thin provider driver," which is usually weeks-to-months of roadmap time returned to feature work.
• Multi-provider / provider-portability roadmap: because the core is decoupled from a specific gateway, it de-risks decisions like "launch with Stripe, add Paddle or a regional processor for EU/APAC" or "renegotiate rates without a rewrite." This is a strategic lever, not just a technical one — it keeps processor fees and terms negotiable.
• Pricing and packaging experiments: plan changes, upgrades/downgrades with proration, trials, coupons, and seat-based tiers become configurable domain objects rather than bespoke code. That lowers the cost of running pricing tests and shortening sales cycles on annual/committed plans.
• Churn and revenue-recovery roadmap: subscription lifecycle events (renewal failed, past due, canceled) give a clean hook for dunning emails, grace periods, and involuntary-churn reduction — a common high-ROI PM initiative that's painful to retrofit.
• Self-serve billing surface: payment-method updates, invoice history, and cancellation flows are the raw material for an in-app billing portal, which typically reduces support tickets per account.
• Release v2.6.1: patch-level version bump with no documented breaking changes, deprecations, or new features in the supplied notes (the changelog is a commit link only). Treat as low product risk / unverified technical risk; do not let it move roadmap dates, but do gate any upgrade on a diff review and an exact version pin.

When to Consider This Package

Adopt when:

• The product is a Laravel application on a currently supported Laravel/PHP line, and billing is expected to be a first-class, long-lived domain rather than a single checkout button.
• You need recurring revenue primitives — trials, proration, plan switching, dunning states, invoice records — and want them as reusable, testable contracts instead of controller spaghetti.
• Provider flexibility is on the roadmap, or procurement/leadership wants optionality on payment processors and rates.
• Your team can own a Composer dependency: track releases, review diffs, run migrations, and handle webhooks idempotently in production.
• You want billing logic to be framework-native and inspectable (events, Eloquent models, queues) rather than a black-box hosted billing portal.

Look elsewhere when:

• You need one-off or simple one-time payments — the provider's own SDK/Checkout is less code and less abstraction.
• The stack is not Laravel/PHP, or billing lives in a separate polyglot service where a PHP package can't be the source of truth.
• You require a commercial SLA, vendor indemnity, or certified tax/invoicing compliance (multi-jurisdiction VAT, e-invoicing) — that's a buy decision for a billing platform, not an OSS package.
• No one can own billing operations (webhook retries, reconciliation, failed-payment runbooks). The package gives you the model; it does not give you the on-call rotation.
• Regulatory or audit constraints demand a maintained-by-contract dependency; assess maintainer concentration and release cadence first.
• v2.6.1 specifically: if your policy is "no patch upgrades without documented change notes," this release does not satisfy it — defer until the changelog or diff is reviewed, and hold the prior pinned version in the meantime.

How to Pitch It (Stakeholders)

For executives (30 seconds): We're evaluating cashier-provider/core, an open-source Laravel package that gives us the subscription-billing foundation — plans, trials, upgrades with proration, invoices, failed-payment handling — without building it ourselves. The business case is speed and leverage: it shortens time-to-revenue on paid tiers, avoids a multi-month internal billing build, and keeps us provider-agnostic, so we can add or switch payment processors without a rewrite or renegotiate from a locked-in position. Cost is engineering ownership time (dependency tracking, webhook operations), not licence fees. The current release, v2.6.1, is a patch with no documented breaking changes — we'd pin the version and review the diff before any production upgrade.

For engineering (the honest version): The package is a domain core, not a turnkey integration — we still write and own the provider driver, webhook verification and idempotency, and the migration path for billing tables. In exchange we stop re-implementing subscription state transitions per project and get testable contracts. Risks to size before committing: maintainer concentration and release cadence, quality of upgrade notes (v2.6.1 ships a commit link only — no summary), and the operational burden of billing correctness, which is ours regardless of package choice. Recommendation: time-boxed spike — wire one provider end-to-end against a sandbox, exercise upgrade/downgrade, failed renewal, and webhook replay, then decide with real data rather than a README.