Filament Cashier Billing Provider Laravel Package

Product Decisions This Supports

• Build vs. buy for tenant billing UI. This fills a narrow but high-friction gap: the "tenant picks a plan, pays, and hits a paywall" loop inside a Filament admin panel. Without it, that's a Stripe Checkout integration, a plan-selection screen, and subscription-gating middleware built from scratch — roughly 2–4 weeks of undifferentiated work.
• Monetization model iteration without engineering. Plans are config-driven (product_id, price_id, type, trial_days vs. has_generic_trial, allow_promotion_codes, collect_tax_ids, metered_price). Trial length, promo-code eligibility, tax-ID collection, and metered-vs-flat pricing become config changes you can decide and ship in a day rather than roadmap items.
• Paywall strategy. ->requiresTenantSubscription() is opt-in, and the RedirectIfUserNotSubscribed middleware is available independently. That lets you decide per panel whether subscription is mandatory — useful for freemium vs. hard-paywall tests, and for keeping internal admin panels out of the gate.
• Plan catalog packaging. Multiple-plan support (v2.1.0+) and backed-enum plans (v1.8.0) let you model plans as a PHP enum, giving compile-time safety against config typos before they hit production checkout.
• B2B / EU go-to-market readiness. collect_tax_ids is a real product decision (VAT / reverse charge), not a checkbox. If you sell to businesses in the EU, this package is the difference between launching there and deferring.
• Usage-based tiers. Metered price support unlocks a usage tier at checkout without custom metering plumbing — worth scoping explicitly if it's on the roadmap.
• Low regret on architecture. This is a thin adapter over Laravel Cashier, so Stripe stays the source of truth and the subscription model is not proprietary. If you later replace Filament or redesign the billing surface, you're not migrating billing data.

Constraints that shape scope: recurring subscriptions only (no one-time purchases, invoices, dunning, or credits UI), and the Billable model must be the same as the Filament tenant model — so per-user billing is out of scope by design.

When to Consider This Package

Adopt when most of these hold:

• You're on Filament v4 or v5 (v3 support was removed in 3.0.0), Laravel 12/13 (Laravel 11 dropped in 3.1.0), and Cashier Stripe 15/16.
• Your billing entity is the tenant (team / workspace / organization) and that model is Billable.
• You sell a small, static catalog of recurring Stripe subscriptions — a handful of plans, not a matrix.
• You want billing inside the admin panel rather than on a separate marketing-site checkout.
• You need trials, promo codes, tax IDs, or metered pricing — and specifically those, nothing more.
• Your team is small enough that buying 100-ish lines of glue code beats owning it.

Look elsewhere when:

• You need one-time purchases, credits, invoice history, dunning, proration UI, or seat-based quantity add-ons beyond what Cashier exposes. You'd be building on top, which changes the buy calculation.
• Billing is per-user, not per-tenant.
• You're on Filament v3 or Laravel 11 — adoption forces a framework upgrade first.
• You need multi-gateway support (Paddle, Lemon Squeezy); this is Stripe/Cashier-specific.
• Vendor risk is unacceptable. Single maintainer, 104 stars, zero dependents — a real bus-factor concern for revenue-critical code. Mitigation: pin the version and budget for owning a fork. The maintainer monetizes a separate paid plugin, which is a positive maintenance signal but also means this package is a loss-leader: expect steady dependency upkeep, not aggressive feature expansion.
• You need a public-facing pricing page with rich plan comparison — this is admin-panel UI, not a marketing surface.

How to Pitch It (Stakeholders)

Executives: "Stripe billing for our tenant admin panel is table stakes and not a differentiator. This MIT package gives us plan selection, trials, promo codes, tax-ID collection, and subscription gating through about ten lines of panel configuration instead of a multi-week build. It tracks the ecosystem closely — Laravel 13, PHP 8.5, and Filament 5 are already supported. Risk is contained because it's a thin adapter over Laravel Cashier: Stripe remains the system of record, and we can remove the package without migrating billing data. The one constraint to accept up front is recurring subscriptions only, billed to the tenant."

Engineering: "We register a BillingProvider on the panel and add a plans array to cashier.php. Our Billable model must be the tenant model. Cashier and Stripe sit underneath, so there's no new data model to own. Two things to verify before committing: the version matrix (needs Filament 4/5, Laravel 12/13) and the coverage boundary — no one-time charges, invoices, dunning, or usage dashboards, so if the roadmap needs those we're building on top. With a single maintainer and no dependents, pin the version and treat a fork as a plausible fallback."

Suggested ask: a one-day spike wiring it into a staging panel to confirm the paywall middleware behaves correctly against our existing tenancy setup.