Jetstream Cashier Billing Portal Laravel Package

Technical Evaluation

Architecture fit: This release positions the package on the Laravel Cashier 13.x / Cashier Register 6.0 dependency line. It is a fit for applications already on a supported Laravel version and planning to use Cashier 13.x for Stripe billing. It is not a fit for Laravel 7 applications or teams not ready to absorb the Cashier 13 upgrade.

Integration feasibility: The upgrade is feasible only after a version audit. Teams must confirm app Laravel version, PHP version, Cashier version, Stripe API assumptions, and any custom billing models or direct Cashier Register usage. The Cashier 13 upgrade guide should be treated as mandatory reading before changing the package constraint.

Technical risk: This is a dependency-chain release, not a standalone feature update. Primary risks are Laravel 7 incompatibility, Cashier 13 behavioral or schema changes, Cashier Register 6.0 API changes, webhook/subscription regressions, and payment-state drift during migration. Billing code has low tolerance for partial upgrades.

Key questions: Which Laravel, PHP, and Cashier versions are in production? Are there custom Cashier models, migrations, or webhook handlers? Does the app call Cashier Register APIs directly? Is Stripe test-mode coverage sufficient for subscription lifecycle, invoices, refunds, and payment-method changes? What is the rollback path if billing state diverges?

Integration Approach

Stack fit: Target stack should be a currently supported Laravel version, Cashier 13.x, and Cashier Register 6.0. Treat Laravel 7 as unsupported for this release line. Confirm exact Composer constraints rather than relying on release-note shorthand.

Migration path: Sequence as follows: audit current Laravel/Cashier/package versions; upgrade Laravel if required; upgrade Cashier to 13.x using its upgrade guide; upgrade Cashier Register to 6.0; upgrade this package to 4.2.0; run migrations and config checks; execute billing regression tests in staging.

Compatibility: The main compatibility boundary is Cashier 13.x. Validate transitive dependencies, PHP version, database migrations, Stripe webhook behavior, and any package-specific configuration. Do not combine this upgrade with unrelated billing feature changes.

Sequencing: TPM should sequence this as a dedicated billing dependency upgrade: version audit, engineering spike, staging validation, webhook replay tests, canary release, then production rollout with monitoring. Block release for any application still on Laravel 7 or Cashier versions below 13.x until the platform upgrade is complete.

Operational Impact

Maintenance: The package now tracks a newer Cashier/Register line, which increases coordination but reduces legacy Laravel 7 support burden. Maintenance should include routine checks against Laravel, Cashier, Cashier Register, PHP, and Stripe API changes.

Support: Support teams will need updated runbooks for subscription failures, webhook failures, invoice mismatches, and payment-method issues. Escalation paths should include application engineering and, where relevant, Stripe support.

Scaling: The package is unlikely to be the primary scaling bottleneck; Stripe API limits, webhook throughput, queue workers, and database transaction contention are more likely constraints. Ensure webhook processing is idempotent and monitored.

Failure modes: Watch for incompatible dependency resolution, failed migrations, webhook signature or delivery failures, subscription state drift, payment retries behaving differently under Cashier 13, and Laravel 7 breakage. Rollback must account for billing data and webhook replay, not just code deployment.

Ramp-up: Engineering needs familiarity with Cashier 13 upgrade mechanics, Cashier Register 6.0 changes, and Stripe billing lifecycle testing. TPM should allocate time for a staging validation cycle and a controlled production rollout rather than treating 4.2.0 as a routine patch.