Stripe Cashier Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on billing plumbing. Subscription lifecycle, proration, invoice retrieval, and webhook handling are commodity work with high blast radius. This package is a candidate to buy (adopt) so engineering time goes to product surface instead of Stripe API choreography. v1.6.0 widens the "buy" surface: metered billing, multi-plan subscriptions, and automatic tax now ship in the box, which moves three previously-custom workstreams into the commodity column.
• Time-to-first-revenue for a self-serve pricing page. If the roadmap has "launch paid plans" in the next quarter, a Cashier-style abstraction collapses the estimate from weeks to days for the 80% case: create customer, attach subscription, store price/plan, react to customer.subscription.updated/deleted. Unchanged by this release, and still the strongest argument for adoption.
• Pricing model ambition is no longer a v1 constraint. Earlier guidance said usage-based metering and tax were explicitly out of scope for v1. v1.6.0 reverses that: Meters API for metered billing (replacing the deprecated createUsageRecord path) and automatic tax wired end-to-end with customer tax IDs mean a hybrid seat-plus-usage plan or a tax-compliant EU launch is now a configuration question rather than a separate build. This is the headline product change — it removes the two most common reasons a SaaS roadmap defers billing scope.
• Packaging and bundling options expand. Real multi-plan operations means the data model now supports a billable entity holding more than one plan/subscription concurrently. That unlocks add-ons, bundled entitlements, platform-fee-plus-product pricing, and "base plan + metered overage" without a schema rewrite or a custom join table. Worth revisiting if the roadmap has ever discussed bundles or add-ons as a post-launch lever.
• Entitlement model as a product decision. Adopting a Cashier-shaped data model (billable entity → subscription(s) → price) forces an explicit answer to "what does a paying customer get?" and makes gating logic webhook-driven rather than UI-driven. The move to multi-plan makes the entitlement question sharper: entitlement checks must now aggregate across subscriptions, not read a single row. Decide that before adoption, not after.
• Scope negotiation on billing edge cases — narrowed but not eliminated. Still out of scope: dunning customization, multi-currency, marketplace/Stripe Connect payouts, revenue recognition, procurement-grade audit. Automatic tax covers calculation and tax IDs, not filing or remittance. Making the remaining exclusions explicit still prevents scope creep.
• Ecosystem reality check. This is a Symfony 8 bundle, not a Laravel package. If the product is on Laravel, the decision is already made — use the official laravel/cashier. If the product is on Symfony, this is one of the few Cashier-flavored options, and that scarcity is itself the strategic argument.

When to Consider This Package

Adopt it when all of these hold:

• The application is on Symfony 8 (or you can pin to it). It is explicitly built for Symfony 8, so it will not help a 6.4 LTS or 7.x codebase without compatibility work.
• You are greenfield on billing — no existing subscription tables, no legacy Stripe integration to reconcile.
• Your billing model is the standard SaaS shape: recurring subscription to a fixed Stripe Price, one billable entity per account, invoices viewed/downloaded rather than generated. You may now additionally want metered/usage-based pricing, multiple concurrent plans per account, or automatic Stripe Tax — but treat those three as newly claimed, not yet battle-tested (see the maturity criteria below).
• You have no dedicated billing/payments engineer and one or two developers who can read the package source and own webhook security themselves.
• You accept the maturity trade: ~21 stars, 0 dependents, and a single-maintainer profile mean effectively no community validation. v1.6.0 shipped a substantial feature set (meters, multi-plan, tax) with no prior production track record; these are the least-exercised paths in the bundle. That's tolerable only because the MIT license lets you fork, vendor, and maintain it internally — plan for that from day one rather than as a fallback.
• You treat it as an accelerant for the last mile, not a foundation you can't leave: put your own interface around subscription state so the package can be swapped.

Look elsewhere when:

• You're on Laravel. Use official laravel/cashier — better maintained, better documented, larger community, and the naming here will only cause confusion in review.
• You need Symfony LTS support or any long-term framework stability guarantee. A Symfony 8-only dependency is a framework-upgrade treadmill commitment.
• Billing is a differentiator, not a cost center in ways this release still doesn't reach: multi-currency, marketplace or Stripe Connect payouts, tax filing/remittance, revenue recognition, or procurement-grade audit requirements. Note the change: usage-based/metered pricing and tax calculation are no longer valid reasons to look elsewhere on paper — but if they are load-bearing to the business model rather than a small slice of revenue, a package with 21 stars is not where you want that logic to live.
• You need vendor accountability — an SLA, security questionnaire responses, or a support contract. Single-maintainer OSS cannot supply these; MIT + a fork is the honest answer, and only viable if you have the headcount.
• The team can't own Stripe webhooks directly. Cashier-style packages hide enough of the webhook contract that debugging a failed payment without Stripe fluency is painful. Metered billing and multi-plan raise the webhook surface area (invoice.payment_failed on usage invoices, proration across concurrent plans); if nobody on the team has shipped Stripe billing, budget for that learning either way.

How to Pitch It (Stakeholders)

To executives: Billing is a solved problem we should not solve twice. This is an MIT-licensed Symfony 8 bundle that gives us subscription records, invoice retrieval, Stripe webhook handling, and — as of v1.6.0 — metered/usage-based billing, multiple concurrent plans per account, and automatic tax with customer tax IDs. That last group matters commercially: it means usage-based pricing and a tax-compliant launch across EU/UK customers are available at launch instead of being a phase-two build. The realistic alternative remains 4–8 engineer-weeks of custom Stripe integration plus permanent maintenance, and the new features push that estimate up, not down. The catch is unchanged and now more pointed: ~21 GitHub stars, zero known dependents, single maintainer, and the v1.6.0 features are brand new — we'd be an early adopter of exactly the code paths we'd depend on. Because it's MIT, we can vendor and maintain a fork, so this is a low-cost bet with a bounded downside, not a lock-in. Recommendation: approve a two-week timeboxed spike behind an internal interface, ship one simple recurring plan through it first to validate the core, then extend to metered pricing or multi-plan only after that holds. Re-decide before committing the full pricing page.

To engineering: Treat this as a starting scaffold, not a dependency you trust blindly. Three non-negotiables: (1) wrap it behind our own Billing interface so the package never leaks into controllers or domain logic — this matters more now, because multi-plan means subscription state is a collection, not a row, and we should own that aggregation; (2) own the webhook endpoint ourselves — signature verification, idempotency keys, and a replay-safe job queue are our responsibility regardless of what the bundle provides; (3) write contract tests against the Stripe test-mode fixtures we care about and pin the version, because a single-maintainer package can go quiet. Release hygiene is a live concern: v1.6.0 also removed the auto-tag CI workflow (to stop phantom releases), so tagging is now manual — pin exact versions and diff before bumping. Two upgrade notes: the Meters API replaces the deprecated createUsageRecord path, so any spike code written against the old usage API will break; and the release refactored quantity method signatures alongside the meter payload hardening, so expect a small but non-zero migration if you prototyped on v1.5.x. Validate automatic tax against Stripe test clocks and a real EU tax-ID scenario before promising finance anything. It targets Symfony 8 only, which is fine for a greenfield service and disqualifying for anything on an LTS. Budget a few days to read the source before the spike ends — we need a named internal owner before this merges.