Spark Billing Provider Laravel Package

Technical Evaluation

Architecture fit. filament/spark-billing-provider is a small satellite package inside the Filament monorepo (packages/spark-billing-provider), not a first-class product. Its architecture is that of a billing provider adapter: it slots into a Filament panel's service-provider/contract layer so that subscription and billing UI (plan display, plan switching, cancellation, payment-method management) renders through Filament's schema/action component system instead of hand-rolled Blade. That is a good architectural fit only if three things are simultaneously true: you are on Laravel, you are on a Filament panel, and Laravel Spark is your billing engine. Remove any one and the package has near-zero value — it is glue, not a capability.

Integration feasibility. Mechanically easy: a Composer require, provider registration, a config publish, and panel wiring. The real feasibility question is dependency depth, not install effort. The provider is coupled to Spark's models, tables, and version constraints, which are themselves coupled to specific Laravel releases. Spark is a commercially licensed, slow-moving first-party package; its release cadence does not track Filament's. That creates a three-way version constraint (Filament major ↔ Spark major ↔ Laravel major) that we would have to own.

Technical risk. High, and mostly unobserved risk rather than known defects:

• Zero dependents. No public install base means no field validation, no community bug reports, no de facto compatibility matrix. We would effectively be the primary consumer.
• Monorepo release coupling. The package has no independent release history; "last release 2026-10-26" reads as a monorepo-wide tag (and is a future-dated artifact — a data quality flag, not a maturity signal). Filament majors ship breaking changes; this package will inherit them whether or not anything billing-related changed.
• The 32,383 stars are Filament core's, not this package's. Opportunity score of 3.63 and a composite score of ~61 should be read as "large parent ecosystem, negligible standalone pull." Do not let core's popularity underwrite the decision.
• Maintenance ambiguity. AGENTS.md explicitly lists it among peripheral packages, with no owner, no skill file, and no testing guidance specific to it — a structural hint about upstream investment.

Key questions to resolve before committing:

1. Is the provider behind a BillingProvider contract we can implement for Cashier/Stripe/Paddle, or is Spark hard-required? If the former, we get the UI layer without the Spark lock-in.
2. Which Filament major is this pinned to, and is a v4-compatible branch published to Packagist as a split repo or only available via the monorepo?
3. Does the package own migrations, or does it read Spark's existing tables read-only? The latter is a materially cheaper rollback.
4. Who is accountable upstream for issues filed against a 0-dependent subpackage, and what is the realistic triage expectation?
5. Does it degrade safely if the panel is installed without Spark (boot-time failure vs. graceful absence)?

Integration Approach

Stack fit. Laravel + Livewire + a Filament panel, with Spark as the subscription engine. If our billing is Cashier-based, this package is the wrong starting point; the correct move is to implement Filament's billing-provider contract ourselves (or build the ~4 billing pages as panel resources) rather than adopt Spark to justify the adapter.

Migration path. Treat this as a UI-layer extraction, not a billing migration. Spark's tables, webhooks, and Stripe customer records stay untouched; only the presentation and mutation surface moves into the panel. That makes rollback cheap and is the strongest argument for the package if we are already on Spark. Sequence it behind a feature flag with the legacy routes left live.

Compatibility. Pin Filament, Spark, and Laravel as a single coupled upgrade unit in composer.json — no floating constraints on any of the three. Add a CI job that runs the panel's billing tests against the locked matrix so a Filament minor bump fails loudly rather than in production. If upstream ships only from the monorepo tag, vendor the package or maintain a fork with our own tags.

Sequencing.

1. Branch spike: install against our exact Filament/Spark/Laravel matrix, confirm the panel boots and renders billing pages.
2. Read-only cutover first — plan display, invoice history, current subscription state — in staging against Stripe test mode.
3. Write paths second — plan change, cancellation, payment-method update — with Stripe webhook replay tested.
4. Authorization and policy review of every new panel route before exposure.
5. Decommission legacy routes only after a full billing cycle has passed without discrepancy.

Operational Impact

Maintenance. Assume ownership. With 0 dependents there is no crowd to surface regressions; the realistic posture is "fork on first breakage." Budget a recurring line item for upgrade work at every Filament major, plus opportunistic breaks at minors.

Support. No SLA, no vendor relationship, community channels only. We need an internal runbook covering: how billing pages are wired, where Spark state lives, how to disable the panel's billing surface in an incident, and who to escalate to. That runbook is mandatory, not optional, because the knowledge will otherwise live with one engineer.

Scaling. Throughput is a non-issue — billing screens are per-user, low-QPS. The scaling risk is state consistency: entitlement checks that read Spark models from panel actions can go stale relative to Stripe webhooks, and cached subscription status is the classic source of "user paid but is still locked out." Make entitlement reads authoritative or explicitly cache-invalidated on webhook receipt.

Failure modes to instrument.

• Silent breakage after a Filament major/minor upgrade (no upstream test coverage to catch it).
• Three-way version drift producing a panel that boots but renders broken billing components.
• Webhook endpoint or signature changes stranding subscription state.
• Authorization gaps — a misconfigured policy exposing another tenant's invoices in a panel context.
• Migration/seeder assumptions on Spark tables that conflict with our schema.

Ramp-up. Low for engineers fluent in Filament's fluent make() + closure API — the patterns mirror the rest of the panel. The real learning cost is Spark's domain model and Stripe webhook semantics, which this package does not abstract. Estimate days for a Filament-fluent engineer to ship read-only views; weeks to responsibly own the write paths. Plan for a single named owner, because with no upstream community, bus factor is 1 by default.