- How do I install and set up lemonsqueezy/laravel in a Laravel application?
- Install the package with Composer, then publish its config file and migrations. Set your Lemon Squeezy API key and webhook signing secret in the environment, expose a webhook route that bypasses CSRF and is reachable in every environment, and run a queue worker for webhook jobs. The evaluation estimates a competent Laravel developer can reach a working sandbox checkout in one to two days.
- Which Laravel and PHP versions does lemonsqueezy/laravel support?
- The provided evaluation does not pin specific Laravel or PHP version ranges and notes release metadata dated 2026-03-20 that looks forward-dated. Verify actual constraints on Packagist and in the repository's composer.json before committing. Also review the maintainer's upgrade track record across major Laravel releases, since that is an open question in the assessment.
- Does lemonsqueezy/laravel verify webhook signatures and handle idempotency?
- The package provides a webhook entry point and setup requires a webhook signing secret, so signature verification is part of the intended flow. Idempotency is not something the evaluation credits to the package: it states that anything beyond the happy path, including idempotency, retries, and reconciliation, is your responsibility. Webhook delivery is at-least-once and can arrive out of order, so plan an idempotency store and a state machine to avoid corrupting entitlements with duplicate or stale events.
- Who should be the source of truth for subscription state, Lemon Squeezy or my database?
- Lemon Squeezy is the merchant of record and should be treated as system of record for payment state, while your database owns entitlements derived from it. The greenfield guidance in the evaluation recommends exactly that split and warns that vendor semantics such as subscription statuses and license keys will leak into your models unless you wrap the package. Define a reconciliation policy up front, because reconciling local state against Lemon Squeezy is a named friction point.
- Can I add subscriptions and license keys without building a full billing engine?
- Yes. The package is a thin SDK over the Lemon Squeezy REST API offering checkout, subscriptions, license keys, a Billable-style trait, events, and Blade components. It is explicitly a convenience layer, not a billing engine, so dunning, retries, and reconciliation remain yours. Scope whether you actually need license keys, checkout overlays, and the customer portal, since each feature adds vendor surface you absorb.
- How hard is it to migrate from Stripe Cashier, and will both packages conflict?
- The evaluation says a move from Stripe or Cashier is not a drop-in replacement, though vendor lock-in is bounded because the Lemon Squeezy API surface is small. It advises checking for conflicts with laravel/cashier if you dual-run both packages, and for route or middleware collisions on the webhook path. Migrating existing subscribers is the expensive part, not the code, so plan that as a separate workstream.
- Is lemonsqueezy/laravel safe for production and revenue-critical billing?
- It is a small MIT-licensed package with no SLA, and the evaluation cites 591 stars with zero dependents as a narrow adoption signal meaning limited community battle-testing. The main technical risk is a revenue-critical dependency on one external SaaS plus a lightly adopted package. Common mitigation is wrapping the package behind your own billing interface and owning webhook operations and the on-call story for billing incidents.
- Does lemonsqueezy/laravel work with multi-tenant apps, teams, and multi-currency?
- These are listed as open questions in the evaluation rather than settled features. Mapping Lemon Squeezy subscriptions onto an existing users, teams, or tenancy model is called out as a primary friction point, and multi-currency is listed as an unresolved concern. Verify both against your data model before adoption rather than assuming support.
- Does the package work with queues, Redis Horizon, and Laravel Octane?
- The stack fit notes it works in a queue-backed stack such as Redis with Horizon and under Octane, and that it has no frontend opinion because checkout is typically a hosted Lemon Squeezy page. Running a queue worker is part of the documented setup path. Confirm compatibility with your exact Laravel and PHP versions and any tenancy or auth packages first.
- What if my billing logic is deeply entangled with entitlements, metering, or custom proration?
- The evaluation calls this a poor fit. The package exposes vendor semantics like subscription statuses, license keys, and checkout URLs that will leak into your models unless you wrap it. If billing is a differentiator rather than a cost-conscious launch feature, keep the SDK behind your own interface or consider a billing engine instead.