- Can I install mmanos/laravel-billing in a Laravel 11 application?
- No. The package targets Laravel 4.x and pins Illuminate 4.x components, so Composer resolution fails on Laravel 5 through 11. Forcing installation with ignore-platform-reqs only converts a dependency error into a runtime error. Treat it as a reference for billing domain modeling, not as a dependency for a modern Laravel app.
- What Laravel and PHP versions does mmanos/laravel-billing require?
- It is a Laravel 4 package and expects the PHP 5.4 to 5.6 era runtime. Laravel 4 has been end-of-life since 2015 and receives no security patches. The package's last release was 2017-11-11, so it is not a supported option for PHP 8.x or any current Laravel version.
- How do I install mmanos/laravel-billing?
- Installation only makes sense inside a preserved Laravel 4 application, using Composer and then registering the package's service provider and facade per Laravel 4 conventions. There is no supported installation path for Laravel 5-11; composer require will refuse or require platform-req overrides. Do not install it into a modern application just to borrow its models.
- Does mmanos/laravel-billing support Stripe SCA, 3DS2, and idempotency keys?
- No. Its 2014-2017 vintage predates Stripe's modern API versioning discipline, SCA/3DS2 and PSD2 strong customer authentication flows, idempotency-key conventions, and current webhook signing. Integrating it today would mean building on deprecated payment primitives. That is a disqualifying gap for production billing.
- Is mmanos/laravel-billing safe to use for production payments?
- No, not for anything touching money in a supported stack. It stacks an end-of-life framework, an end-of-life PHP runtime, and an unmaintained payment integration in the same dependency. Billing code is also in PCI DSS scope, and an unaudited package with unknown test coverage and a single maintainer is hard to defend to a security reviewer.
- What features does mmanos/laravel-billing provide?
- It provides a Laravel subscription billing domain for plans, coupons, invoices, and recurring payments, with Eloquent models and traits for billable users and subscriptions. It integrates with Stripe using the gateway conventions of its era. The vocabulary is useful for requirements discovery around subscriptions and invoicing, but the implementation is not a modern dependency.
- What are the best alternatives to mmanos/laravel-billing for Laravel subscriptions?
- For supported Laravel versions, Laravel Cashier is the native starting point for Stripe or Paddle subscriptions. Hosted billing platforms such as Stripe Billing, Chargebee, and Paddle are alternatives when you want less billing logic in your application. Compare those costs with the cost of forking and indefinitely maintaining a Laravel 4-era package.
- Can I use mmanos/laravel-billing with Laravel 5, 6, 7, 8, 9, 10, or 11?
- No. It is explicitly a Laravel 4 package, and framework package discovery, container bindings, events, queues, and Eloquent behavior all changed materially after 4.x. It is not architecturally portable to Laravel 5-11. The only plausible runtime is a frozen Laravel 4 monolith.
- Is mmanos/laravel-billing actively maintained?
- No. The last release was 2017-11-11, the project has roughly 46 stars, and it has a single maintainer with no visible security-response process. That is light maintenance at best, not active support. If you adopt it, plan to own and fork the code indefinitely.
- How should I evaluate or test mmanos/laravel-billing before trusting it?
- Only evaluate it inside a disposable legacy Laravel 4 environment, and characterize behavior against a Stripe sandbox before trusting any charge path. Check idempotency, webhook replay protection, and partial-failure behavior between a successful gateway charge and the local database commit. Given the package's age, assume weak test coverage and validate modern SCA/3DS2 flows separately if you are considering a rewrite.