Weave Code
Laravel Subscriptions Laravel Package
laravelcm/laravel-subscriptions
Laravel Subscriptions is a flexible plans and subscription management system for Laravel, with tools to run SaaS services efficiently. It provides migrations, config, and Eloquent models; payments are out of scope.
Laravel Subscriptions is a flexible plans and subscription management system for Laravel.
Frequently asked questions about Laravel Subscriptions
- Does laravelcm/laravel-subscriptions handle payments, invoices or taxes?
- No. Payments are explicitly out of scope for this package: it does not talk to Stripe, Paddle or any gateway, and it does not process payments, invoicing, tax, refunds or dunning. It only provides the plans, features and subscriptions data model. You pair it with Laravel Cashier, Paddle or a custom payment service, then drive subscription state transitions from gateway webhooks with idempotency.
- How do I install laravelcm/laravel-subscriptions in a Laravel app?
- Run composer require laravelcm/laravel-subscriptions, then publish config and migrations with php artisan vendor:publish --provider="Laravelcm\Subscriptions\SubscriptionServiceProvider", and finally run php artisan migrate. That covers the base install; afterwards you wire the HasSubscriptions trait into your subscriber models and define your plan catalog. Because the migrations are published into your application, treat them as files you own rather than a black box.
- Which Laravel and PHP versions does laravelcm/laravel-subscriptions support?
- The README badges Laravel 10.x, so check the composer.json constraints on Packagist for the current PHP and Laravel support matrix before committing. The package may lag behind the newest Laravel majors, so confirm the maintainers' policy for new majors first. Pin both the package version and your Laravel major explicitly in composer.json, and run a smoke test on your target PHP version in staging.
- How do I add subscriptions to my existing User model?
- Add the HasSubscriptions trait to your User model (or your tenant model) to get the relationships and helper methods for plans and subscriptions. Models are swappable through config-driven bindings, so you can extend the package base classes instead of editing vendor code. If your authentication model is unusual, you can also implement the subscriber contract directly. Validate with a smoke test that creates a subscriber, assigns a plan and reads back entitlements.
- Can I extend or replace the package's Eloquent models?
- Yes. Model bindings are configuration-driven, so you can point the package at your own classes that extend its base models and override helpers such as renew(), cancel() or changePlan(). This is the recommended approach when cancelling a subscription should also cancel a recurring payment record. Keeping customizations in app-level subclasses makes future package upgrades easier to diff and merge.
- Does it support usage-based or metered billing?
- The schema includes optional usage records, so you can track metered features and consumption against a subscription. It does not rate usage, compute proration, or generate invoices, so any aggregation, pricing tiers and billing for that usage are your responsibility. If metered billing is central to your product, plan for a separate rating and invoicing layer alongside this package.
- Can I use it for a multi-tenant SaaS with multiple subscribers?
- Subscribers are plain Eloquent models, so a tenant model can use the HasSubscriptions trait just as a User can. Multi-tenancy then depends on your own query scoping, since the package does not impose a tenancy convention. Multiple subscribers per tenant needs deliberate design around which model holds the subscription; test entitlement resolution carefully in that setup. Database driver and timezone handling for period boundaries should also be validated.
- How are upgrades, downgrades, trials and cancellation at period end modeled?
- The package stores subscription periods and offers state transitions such as renew(), cancel() and plan changes, which you extend or wrap in application services. Proration math, trial handling, grace periods and cancellation-at-period-end semantics are product decisions you implement, not built-in billing logic. Map these rules with your product team before adopting, and cover them with edge-case tests around period boundaries and clock timezones.
- Is laravelcm/laravel-subscriptions actively maintained and safe for production?
- Release cadence looks active, and CI badges for tests and coding standards are present in the README. The main risk is ecosystem signal rather than code quality: roughly 244 stars and no recorded dependents point to a small, possibly single-organization maintainer surface, so plan for a bus factor of one or two people. Pin the version, run the package test suite plus your own smoke tests, and budget time to own the dependency if upstream slows down.
- How do I handle migrations and schema upgrades when the package updates?
- Migrations are published into your application, so a package upgrade may require re-publishing and diffing the schema against what you already have. Keep changes additive, such as new indexes or nullable columns, and review diffs before running them on production data. Run upgrades in staging first, reconcile subscription and entitlement counts, and avoid hand-editing published migrations without recording the divergence.
Weaver
How can I help you explore Laravel packages today?