Jetstream Cashier Billing Portal Laravel Package

Product Decisions This Supports

• Build vs. buy for billing/receipts: This package sits on top of Laravel Cashier (Stripe) and Cashier Register, giving you subscription billing plus a receipts/invoices register without building either from scratch. It supports the recurring decision to buy commodity billing plumbing rather than staff it.
• Stripe as the billing rail: 4.2.0 aligns to Cashier 13.x, which effectively commits the product to Stripe's subscription model (plans, trials, coupons, proration, invoice history). Relevant to pricing/packaging decisions that assume those primitives.
• Receipts and customer-facing billing history: Cashier Register 6.0 covers the "download my invoice / see my past charges" surface — a support-ticket deflecting feature that usually shows up on the roadmap right after launch.
• Platform/framework support windows: Dropping Laravel 7.x support is a hard constraint on which apps can adopt this release. This directly informs any decision to stay on or migrate off Laravel 7, and sets the floor for new services.
• Upgrade sequencing: Because 4.2.0 pulls in Cashier 13.x and Cashier Register 6.0, it forces a coordinated Stripe/Cashier upgrade. That's a roadmap dependency to slot alongside framework upgrades, not a routine patch.

When to Consider This Package

Consider it when:

• You're on a Laravel version supported by Cashier 13.x (i.e. Laravel 8+ after this release) and use Stripe for subscriptions.
• You want subscription management and a receipt/invoice register in one dependency, rather than stitching Cashier plus a bespoke billing-history screen.
• Your team is small and prefers thin, opinionated wrappers over bespoke billing code you'd have to maintain through Stripe API changes.
• You're comfortable inheriting a transitive dependency chain (this package → Cashier → Stripe SDK, plus Cashier Register).

Look elsewhere or defer when:

• You're on Laravel 7.x or older — 4.2.0 explicitly drops it, so this release is unavailable to you until you upgrade (pin to 4.1.x and accept the support gap).
• You need multi-gateway billing (Paddle, Mollie, etc.); Cashier is Stripe-shaped.
• You require fine-grained control over Stripe API calls, webhook handling, or usage-based/enterprise metering that the wrapper abstracts away.
• You have no one who can own PHP dependency upgrades — 4.2.0 bundles two major dependency bumps inside what is nominally a minor version, which is a maintenance commitment.
• You're mid-quarter and can't absorb a coordinated Cashier 13.x migration; treat this as a planned upgrade, not a drive-by composer update.

Before upgrading: read the Stripe Cashier 13.x upgrade guide (https://github.com/laravel/cashier-stripe/blob/13.x/UPGRADE.md) and the Cashier Register 6.0.0 release notes. Both majors are prerequisites for 4.2.0.

How to Pitch It (Stakeholders)

To executives: We're evaluating a billing package that provides subscription management and customer receipt history on top of Stripe, so we don't build or maintain that plumbing ourselves. The new 4.2.0 release keeps it current with Stripe's Cashier 13.x, which is the version we need for continued Stripe support. The cost is an upgrade project: it also bumps Cashier Register to a new major and drops Laravel 7 support. If we're on Laravel 7, this release is a forcing function for a framework upgrade — we should either fund that migration or pin to 4.1.x and accept that we stop receiving fixes.

To engineering: Treat 4.2.0 as a breaking release despite the minor version number — it bundles two dependency majors and removes Laravel 7. Sequence it as: (1) upgrade Laravel if needed, (2) upgrade Cashier to 13.x per the official upgrade guide, (3) upgrade Cashier Register to 6.0, (4) bump this package. Verify webhook handling and any overridden billing views/routes after the jump, and confirm test coverage on the receipt/invoice register before rollout.

To product/support: Customer-visible impact should be limited to billing history and invoice downloads; validate those flows in staging. No new customer-facing features are introduced in 4.2.0 — this is a compatibility release, so any roadmap benefit comes from staying current with Stripe rather than from new capability.