Cashier Laravel Package

Technical Evaluation

Architecture fit: Laravel Cashier is a strong fit for a Laravel application that has already selected Stripe as its subscription billing provider. It supplies the Billable trait, subscription and subscription-item models, invoice handling, checkout and billing-portal helpers, webhook handling, coupons, proration, quantities, cancellation grace periods, and invoice PDF generation. As a TPM, the value is primarily buy-versus-build acceleration: it removes boilerplate around Stripe subscription lifecycle management and lets the team focus on entitlements, pricing packaging, and customer workflows rather than raw Stripe API calls. It is a poor fit if the product requires multi-gateway billing, non-Stripe processors, or an abstraction layer intended to hide the billing provider.

Integration feasibility: Integration is feasible for a standard Laravel stack. It requires Composer installation, configuration of Stripe keys, publication and execution of migrations, adding the Billable trait to the customer model, and exposing a signed Stripe webhook endpoint. Recent releases indicate support for Laravel 12, PHP 8.4, Stripe PHP SDK v16, Carbon 3, and dompdf 3.0. The official Laravel billing documentation and changelog reduce discovery risk. The main integration effort is not package installation but billing-domain modeling: mapping products, prices, trials, coupons, tax behavior, entitlements, dunning, and existing subscriptions into Stripe and Cashier’s expected schema.

Technical risk: The primary risk is coupling to Stripe and to Cashier’s opinionated schema and lifecycle conventions. Cashier is an accelerator, not a complete billing platform; edge cases around tax, invoicing, payment authentication, usage-based billing, and subscription migration still require product and engineering decisions. Webhook correctness is critical: missed, duplicated, or out-of-order events can create subscription state drift. Recent changelog entries show fixes for duplicate subscription webhooks, missing payment intents, tax-rate calculation, mass assignment, nullable invoice settings, and SQLite rollback behavior, which is normal for active billing software but reinforces the need for regression tests and reconciliation. The metadata also shows a moderate overall score, a future-dated last release, and zero listed dependents; those signals should be validated against Packagist, the repository release tag, and the actual Laravel ecosystem before treating them as adoption evidence.

Key questions: Which Stripe billing models are in scope: flat-rate, per-seat, metered, usage-based, trials, coupons, or multi-currency? Is Stripe definitively selected, or must the architecture preserve a multi-gateway option? What Laravel, PHP, Carbon, and Stripe API/SDK versions are supported by the existing application? Are there existing subscriptions and invoices that must be migrated without customer disruption? What is the source of truth for entitlements: Cashier tables, Stripe webhooks, or an internal product service? What webhook infrastructure, idempotency strategy, queueing, and reconciliation process exist? What are the tax, invoicing, data-residency, PCI-scope, and support obligations? Who owns upgrades, security patches, and Stripe API-version changes?

Integration Approach

Stack fit: Cashier fits best where Laravel owns authentication, Eloquent models, queues, and HTTP endpoints, and where Stripe is the billing system of record. The package should be pinned to a known-good major version and paired with a deliberate Stripe API version. Avoid mixing Cashier Stripe with Paddle or other Cashier variants. Confirm that the customer model can adopt the Billable trait cleanly, that migrations can be applied safely, and that the application has queue workers and a reliable public webhook endpoint.

Migration path: Start with a billing inventory: plans, prices, coupons, tax rules, trials, discounts, subscription states, invoices, and entitlement mappings. Build a Stripe sandbox and validate the full lifecycle before touching production. Install Cashier in a branch, publish migrations, configure keys and webhook signing secrets, add Billable to the customer model, and backfill Stripe customer IDs carefully. For existing subscriptions, prefer a controlled migration or parallel-run approach rather than a big-bang cutover. Use Stripe as the system of record and treat local Cashier tables as a synchronized projection updated by verified webhooks.

Compatibility: Pin Laravel Cashier, Stripe PHP SDK, Laravel, PHP, Carbon, and dompdf versions together. Review the changelog for breaking changes before every minor upgrade, especially around renamed methods, webhook routing, payment exceptions, and subscription-item schema changes. Validate database support, migration rollback behavior, and static-analysis compatibility. Confirm that the application’s Stripe API version matches the package’s tested expectations and that webhook signature verification middleware is enabled.

Sequencing: First, run a two-to-three-week architecture spike covering checkout, webhook ingestion, subscription creation, cancellation, invoice retrieval, and entitlement checks in Stripe test mode. Second, finalize schema and data migration design. Third, implement idempotent webhook handlers and reconciliation jobs. Fourth, build checkout, billing portal, payment-method update, and dunning flows. Fifth, map entitlements and feature access to subscription state. Sixth, migrate or backfill customers and subscriptions with rollback plans. Seventh, run load, security, and failure-mode tests. Finally, canary a small cohort, monitor reconciliation, then expand. This sequencing de-risks the highest-impact areas: webhook correctness, entitlement drift, and customer-visible billing failures.

Operational Impact

Maintenance: Cashier is actively maintained with frequent patch and minor releases, so the team needs a named owner and a recurring upgrade cadence. Maintenance includes Laravel/PHP compatibility upgrades, Stripe SDK and API-version updates, changelog review, dependency updates, migration testing, and webhook regression testing. Security patches should be treated as production changes with rollback plans.

Support: Official Laravel documentation and the repository changelog are the primary support surfaces. Stripe support covers the billing platform, but not application-specific Cashier behavior. The TPM should define an internal runbook covering failed payments, webhook replay, duplicate subscriptions, invoice disputes, refunds, tax issues, and customer state correction.

Scaling: Webhook volume, queue throughput, database indexing on Stripe identifiers and subscription state, and Stripe API rate limits are the main scaling concerns. Avoid synchronous Stripe calls on latency-sensitive request paths. Process webhooks asynchronously with idempotency keys, deduplication, retries, dead-letter handling, and periodic reconciliation against Stripe. Offload invoice PDF generation and large exports to background workers.

Failure modes: Watch for missed or duplicated webhooks, out-of-order events, subscription state drift, payment-authentication failures, dunning gaps, tax miscalculation, invoice PDF failures, mass-assignment regressions, and migration rollback issues. The v15.7.1 duplicate-subscription webhook fix and earlier fixes for missing payment intents and tax rates are concrete examples of failure classes that should be covered by automated tests and production alerts. Build reconciliation dashboards comparing local subscription and invoice state with Stripe.

Ramp-up: Laravel developers can become productive with Cashier quickly, but Stripe billing literacy is the larger ramp: proration, trials, coupons, tax, SCA, usage-based billing, invoice lifecycle, and dunning. Budget one to two sprints for a sandbox spike, runbook creation, and cross-functional training for engineering, support, finance, and product operations. The TPM should frame Cashier as a leveraged billing accelerator with clearly owned operational controls, not as a replacement for billing-domain ownership.