Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Filament Subscriptions Laravel Package

tomatophp/filament-subscriptions

Filament plugin for managing subscription plans and recurring subscriptions in Laravel admin panels. Define plans and features, assign subscribers, and control access from a clean Filament interface that plugs into your existing billing workflow.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for billing administration. The decision on the table is whether to spend a sprint or more building non-differentiating admin screens — plan CRUD, feature limits, subscription status, renewals, expiry, a billing page — or adopt an MIT-licensed head start. This package is a Filament-native UI and orchestration layer over laravelcm/laravel-subscriptions. Frame it as buying acceleration on admin surface area, not outsourcing the billing domain. Expect roughly a maintenance line, not a build cycle.

  • Roadmap sequencing for a Filament v5 panel upgrade. The package's major version tracks Filament's major version: v5.0.0 targets Filament v5, Laravel 12/13, PHP 8.2+, and laravelcm/laravel-subscriptions 1.8, while Filament v3 users are routed to a 1.x / v3 branch. This package can never be the reason to upgrade the panel, and must never be the reason we cannot — the panel upgrade decision drives it, not the reverse. If a v3→v5 migration is already funded, this is a cheap passenger; if it is not, adopting this package buys a migration program we did not ask for.

  • Self-service billing scope. The billing page now supports configured subscription models, panel URL resolution, and redirects (#20). That means product can commit to in-panel plan selection, upgrade/downgrade entry points, and post-action redirect behavior inside the admin panel. It does not mean a hosted customer-facing billing portal, payment-provider abstraction, invoicing, tax, dunning, or reconciliation. Scope the customer promise accordingly before it reaches a roadmap slide.

  • Pricing and packaging experimentation. Plans, prices, and billing intervals are managed by admin users without custom screens, which supports early packaging experiments and routine operational plan changes at low cost. The precondition is that the plan/feature/subscription schema is the actual source of truth — if it is not, experimentation becomes a reconciliation exercise.

  • Entitlement model ownership. The package assumes plans and features drive feature access. If entitlements also live in a feature-flag service, CRM, or warehouse, adoption creates a two-model problem. This is a real product decision, not an integration detail: either make plans/features authoritative, or explicitly fund syncing entitlement models.

  • Internationalization scope for the plan catalogue. Plan and feature edits now fill every translation, so a multi-language catalogue is achievable without bespoke translation tooling. The tradeoff is that deliberate partial translation is no longer possible — locales intentionally left blank will carry the source-language string. Content owners should hear this before the first demo, not after.

  • Support-ops placement. Active, canceled, and expired subscriptions are visible in native Filament tables and forms. If billing administration belongs in the admin panel rather than a standalone service, this measurably reduces support friction. If it does not, this package is pointed at the wrong architecture.

  • Maintenance budgeting. Single maintainer, 64 stars, zero dependents, no stated long-term-support line, and prior-major support delivered from a branch rather than a maintained release. Treat upgrades as recurring maintenance tied to Filament's cadence, with a local-patch fallback, and name one internal owner of the subscription domain so knowledge does not fragment across two upstream issue trackers.

When to Consider This Package

Consider it when:

  • The product runs Filament v5 on Laravel 12 and PHP 8.2+, and needs plan, feature, subscription, and payment administration inside the existing admin panel.
  • The team has adopted, or will adopt, laravelcm/laravel-subscriptions 1.8 as the domain layer. This is a UI and orchestration layer, not a billing engine.
  • The roadmap needs admin-side subscription management — plans, subscribers, renewals, cancellations, feature access — more than customer-facing payment infrastructure.
  • A ready-made billing page with configurable subscription models and panel URL handling is worth more than a bespoke build.
  • Multi-language plan and feature catalogues are planned and translation auto-fill is acceptable to content owners.
  • Adoption happens at the start of a panel build, or before custom billing screens exist, where integration cost is lowest.
  • The team can absorb major-version lockstep with Filament and will pin Filament, this package, and the subscriptions library together.

Look elsewhere when:

  • You are on Filament v3 or v4. v5.0.0 does not apply to v3, and v4 is not a supported target. Land Filament v5 first; this package is a passenger in that decision.
  • You are below PHP 8.2 or Laravel 12, or cannot adopt laravelcm/laravel-subscriptions 1.8.
  • Billing requires custom recurring logic, invoicing, tax, dunning, payment-provider abstraction, or reconciliation with an external billing platform.
  • You need a hosted billing platform such as Stripe Billing or Paddle rather than in-panel administration.
  • You have no Filament panel, or billing administration is a standalone service. This is not a headless billing API.
  • You cannot tolerate a single-maintainer dependency without guaranteed LTS or backports. Budget for local patching or choose a more established path.

Before committing, verify four cheap items: whether the removed cancels_at column is dropped or left orphaned (an orphaned column returning stale data fails quietly), whether translation auto-fill overwrites non-empty translations or only populates empties, whether Laravel 13 is actually exercised in tests or merely permitted by composer.json, and whether billing-page URL resolution holds behind the real panel path, subdomain tenancy, or reverse proxy. Also get a written answer on the support commitment for the v3 / 1.x branch.

How to Pitch It (Stakeholders)

For executives. We can avoid building subscription administration from scratch. This package gives us plan and feature management, subscription and payment screens, and a billing page inside the Filament admin panel we already run — MIT-licensed, no platform lock-in, no per-seat fee. It keeps us aligned with the current Filament and Laravel stack, fixes first-run setup ordering and renewal issues, ships with a test suite, and has taken an outside contribution. The caveats are real but manageable: it is a small open-source project with a single maintainer and no long-term-support line, and its major version moves with Filament's. That means a scheduled upgrade roughly once per Filament major, budgeted as recurring maintenance rather than absorbed as a surprise. The trade is a modest, predictable maintenance line in exchange for skipping a build cycle on work that does not differentiate us. What we are not buying is a payments platform — invoicing, tax, dunning, and provider abstraction remain ours or a vendor's problem.

For engineering. v5.0.0 aligns with Filament v5, Laravel 12/13, PHP 8.2+, and laravelcm/laravel-subscriptions 1.8, with a clean split: the domain library owns plans, features, subscriptions, and recurring periods; this package owns Filament resources, pages, translations, widgets, billing UI, and install scaffolding. Integration requirements: land Filament v5 first, bump this package and the subscriptions library in the same commit, pin all three to exact versions with no caret ranges, and run the install/migrate path against a production-shaped database rather than a fresh schema. The install-command fix — migrate before creating the main plan — removes a fragile ordering assumption and directly benefits CI seeds, container init, preview environments, and fresh-tenant bootstrap. Inventory and retire every consumer of cancels_at before or with the upgrade. Verify the billing page behind the actual panel path, proxy, and tenancy setup, and spot-check every locale after a plan edit. Land it as an isolated dependency upgrade — the column removal and translation auto-fill are silent behavior changes that are hard to attribute inside a larger release. Assign one engineer as owner of the subscription domain, and confirm we have a local-patch path if upstream stalls.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource