- Does makfly/stripe-cashier-bundle work with Laravel?
- No. This is a Symfony bundle, not a Laravel package, and its Cashier-style API is a re-implementation of Laravel Cashier's subscription semantics on Symfony's service container and Doctrine. On a Laravel stack you should use the first-party laravel/cashier package, which has thousands of dependents plus upstream metered billing via Stripe Meters and Stripe Tax support. There is no scenario where this bundle is the better choice for a Laravel application.
- How do I install makfly/stripe-cashier-bundle?
- Install it with Composer, then register the bundle and publish or write its configuration for API keys, billable model mappings, and billing settings. It is MIT licensed and constrained to symfony ^8, so realistically it targets greenfield projects or applications freshly upgraded to Symfony 8. Older Symfony versions are not covered by the declared constraint.
- Which Symfony and PHP versions are supported?
- The bundle declares a symfony ^8 constraint, which effectively means new or freshly upgraded Symfony 8 applications only. Because Symfony 8 itself targets a recent PHP runtime, check the exact platform requirements in the composer.json before planning an upgrade. Anything below Symfony 8 falls outside the advertised support range.
- Do I have to use the bundle's Doctrine entities, and who owns the database schema migrations?
- The documentation describes reusable billable entities with Doctrine-friendly models and configurable mappings, but it does not clearly state whether shippable entities are provided or whether you must implement a Billable-style interface yourself. Ownership of schema migrations is likewise undocumented. Resolve both questions with the maintainer or a source read before committing, since they determine how invasive the integration is.
- Which stripe/stripe-php version and Stripe API version does it pin?
- The pinned stripe/stripe-php major and the Stripe API version floor are not documented in the available material, so verify them in composer.json and the client initialization code. This matters because the Billing Meters API used in v1.6.0 requires a recent Stripe API version, roughly basil-era or later. If you are pinned to an older API version elsewhere in your stack, the meters feature may not function.
- How does the bundle handle Stripe webhooks and keep local billing state in sync?
- It ships webhook handling intended to synchronize local subscription, invoice, and payment method state with Stripe, which means you configure an endpoint and a signing secret. The real integration cost sits in the webhook-to-entitlement pipeline rather than in the wiring itself. Adding metered usage and automatic tax widens that pipeline, because each domain needs its own event handling, reconciliation, and failure semantics.
- Does it support metered or usage-based billing?
- Version 1.6.0 replaces the older createUsageRecord approach with Stripe's Billing Meters API, so usage-based billing is supported in principle. Note that the change arrived without accompanying test commits, and the quantity method signatures were adjusted in a minor release. Validate meter event emission and reconciliation in your own spike before relying on it for revenue.
- Does the bundle support Stripe Tax and automatic tax calculation?
- The 1.6.0 changelog claims automatic tax is wired end to end, but no tests ship alongside that claim, so treat it as unproven. Real automatic tax support requires address validation, tax ID collection and validation, reverse-charge and inclusive versus exclusive handling, and correct invoice.finalized behavior. Budget for independent verification of each of those paths.
- Is makfly/stripe-cashier-bundle safe to use in production?
- Risk is high: the repository has around 21 stars, zero dependents, and a single maintainer, so there is no downstream compatibility pressure to catch regressions. Release hygiene is also a concern, since an auto-tag workflow was removed because it produced phantom releases on every main push, which means older version numbers may not represent considered, tested releases. Re-verify the provenance of any tag you depend on and avoid treating sub-1.6.0 tags as evidence of stability.
- What are the alternatives to this bundle for Stripe subscription billing in PHP?
- For Laravel, use laravel/cashier, which is first-party, widely depended on, and already covers meters and Stripe Tax. For Symfony, the realistic alternative is integrating stripe/stripe-php directly with your own Doctrine entities and webhook handlers, which gives you full control over migrations, upgrade cadence, and tax logic. Compare that cost against adopting a low-traffic bundle that owns three money-critical domains.