Filament Billing Console Laravel Package

Product Decisions This Supports

• Build vs. buy for internal billing ops: This package collapses a common "should we build an admin screen for subscriptions?" debate into a one-line composer install. For teams already on Cashier + Filament, the default should shift from build to adopt-and-extend, freeing engineering time for product work instead of internal tooling.
• Support and CS tooling roadmap: A read-only, searchable customer/subscription/invoice view (by name, email, or Stripe ID) directly reduces time-to-answer for billing tickets. This is a candidate to ship ahead of, or instead of, a bespoke support console in the next quarter.
• Dunning and involuntary-churn initiatives: Past-due/unpaid counts surfaced next to the menu item, plus a "cancelled, still in grace period" filter, give CS and finance an actionable worklist. This supports prioritizing recovery flows (retry schedules, grace-period emails) with evidence rather than intuition.
• Pricing and revenue health visibility: List-price MRR, active/trialing/past-due counts, and 30-day churn on the dashboard give PMs a lightweight pulse check for roadmap and pricing experiments. Treat it as an operational signal, not a finance-grade metric — list-price MRR does not net out discounts, coupons, or credits, and the churn definition should be reconciled with finance before it appears in any external reporting.
• Access-control and compliance posture: authorizeUsing(), a viewBillingConsole gate, or model policies mean billing data exposure can be scoped to specific roles. The secret key is never rendered, and the tool never mutates Stripe. That materially lowers the risk profile of giving non-engineering staff subscription visibility, and simplifies the access-control narrative in security reviews.
• Buy-vs-extend for mutation workflows: Because it is explicitly read-only, this is a viewing layer, not a billing operations console. Refunds, cancellations, proration, and plan changes remain out of scope — decide deliberately whether those stay in the Stripe Dashboard (lower build cost, weaker audit trail in your systems) or warrant a separate internal tool.
• Data-freshness architecture: "Sync from Stripe" reuses Cashier's own webhook code to write Stripe's copy into your Cashier tables, and invoices/payments are cached from the Stripe API. This is a sound decision to inherit rather than duplicate — it keeps the console consistent with whatever your application already believes about a subscription.

When to Consider This Package

Strong fit when:

• You are on Laravel Cashier (Stripe) and a Filament 4 or 5 admin panel — this is a hard prerequisite; there is no meaningful value outside that stack.
• Support, CS, or finance staff currently ask engineers to look things up in the Stripe Dashboard, or you have no in-app view of subscription state.
• You want read-only visibility fast, with a low blast radius and no new write paths into your billing provider.
• You need role-scoped access to billing data and want it expressed through gates/policies you already govern.
• You want a small, auditable dependency rather than a full billing-analytics platform.

Look elsewhere when:

• You are not on Filament. Retrofitting a panel to adopt a console is the tail wagging the dog; a simple custom page or Stripe's own Dashboard is cheaper.
• You need to take action, not just look. Refunds, cancel-with-feedback, dunning retries, plan swaps, and credit issuance all require write access this package deliberately does not provide.
• You need finance-grade revenue reporting. List-price MRR and a 30-day churn figure are directional. If the number lands in a board deck, investor update, or revenue recognition process, you need net revenue, cohort retention, contraction/expansion, and a documented churn definition from a billing-analytics tool or your own warehouse models.
• You run multiple billing providers (Paddle, Lemon Squeezy, Adyen) or multi-currency/multi-entity billing with complex tax treatment — coverage is Cashier/Stripe-shaped.
• You need a vendor with a support contract, SLA, or security review package. At v1.0.0, this is a young, single-maintainer, unaffiliated open-source package. Adopt it as a convenience, not a critical dependency: pin the version, review the source, and be prepared to fork.
• You have strict procurement or audit requirements around data residency, sub-processors, or a formal SBOM/dependency-review process — the Stripe API calls and caching behavior deserve a security read before rollout.

Adoption caveats worth planning around:

• It reaches the live Stripe API for invoices and payments; cached or not, expect rate-limit and latency behavior to matter at scale, and confirm caching TTLs meet your freshness expectations.
• Compatibility is stated as PHP 8.2–8.5, Laravel 12/13, Filament 4/5 — verify your exact versions, particularly if you are on an older Laravel or PHP 8.1.
• Testing against Stripe's official stripe-mock and a documented browser-check pass are good signals of engineering discipline, but they validate contract shape, not your production data volume or edge-case account states.
• Decide up front who owns upgrades: Filament's major-version cadence will drive breakage risk in a package this young.

How to Pitch It (Stakeholders)

To executives: We can give support and finance a real-time view of any customer's subscription, payment method, invoices, and payment history inside our existing admin panel — for free, in roughly an afternoon of setup, with no new vendor contract. It is strictly read-only: it cannot change, cancel, or refund anything in Stripe, and it never exposes our secret key. The practical result is fewer engineering interruptions for billing lookups and a faster, more consistent answer to "why was I charged?" It also puts MRR, past-due, and churn in front of the team as an early-warning signal. The trade-off is maturity: this is a brand-new, single-maintainer open-source package, so we adopt it as an internal convenience behind our existing access controls and keep the option to fork or replace it. It is not a finance system of record, and the revenue figures should not be used for external reporting without reconciliation.

To engineering: This is a Filament plugin over Cashier's existing tables plus a cached read of the Stripe API — no new data store, no write paths, no webhook endpoints of our own. Authorization is ours to define via authorizeUsing(), a viewBillingConsole gate, or model policies, so it slots into the access model we already have. Its "Sync from Stripe" action deliberately reuses Cashier's own webhook handling code, which means the console stays consistent with what the application already believes rather than inventing a second source of truth. It's version-pinned, tested across PHP 8.2–8.5 and Laravel 12/13, and validated against Stripe's official mock. Costs: one more dependency to track through Filament major upgrades, and we should review the Stripe API call and caching behavior before pointing it at live keys. Recommendation is to install behind a feature flag, scope access to a pilot group in support, and reassess after a quarter of real use.