Cashier Register Laravel Package

Product Decisions This Supports

• Plan tiers and entitlements: Cashier Register sits on top of Laravel Cashier (Stripe/Paddle) and adds a Feature → Quota model per subscription. That makes it the natural substrate for decisions like "which plan gets 5 projects vs. 50," "is SSO included in Pro," and "what happens at the limit." PMs can change tier packaging as configuration/data rather than a re-architecture.
• Metering and usage counters: The 6.0.2 release is relevant here — it fixes double-incrementing of used_total on over-quota paths and adds getTotalUsedQuota() as a first-class read of a feature's total consumed amount. That gives us a single canonical number for in-app usage dashboards ("3 of 10 seats used"), admin/support views, and any future overage reporting. Prior to this, teams were effectively summing used_quota across subscription features themselves and could surface inflated numbers.
• Build vs. buy: The realistic alternative is a bespoke features / quotas / usage schema plus enforcement logic and edge-case handling (downgrades, proration, resets, over-quota semantics). Buying this package is the right call when the requirement is "entitlements and quota checks for a Cashier-billed SaaS," not "a billing system." It removes a multi-sprint build and the long tail of counter bugs that motivated this patch.
• Roadmap enablement: Usage-based and hybrid pricing experiments (seat-based add-ons, credit packs, trial limits, soft vs. hard caps) become a product decision backed by incrementing/injecting usage, rather than a platform project. The over-quota double-count fix also unblocks anything that reports consumption to customers or to finance, since those numbers are now internally consistent.
• Operational/product policy decisions: Hard cap vs. soft cap, whether over-quota is blocking or warning-only, and whether usage is tracked incrementally vs. set absolutely are all policy levers the package exposes. PMs should make these explicit product decisions rather than leaving them to whichever code path the engineer picked.
• Support and trust posture: 6.0.2 is a patch on the 6.x line — no breaking changes, no deprecations. The behavioral change is confined to fixing an incorrect used_total, which means any dashboard, export, or customer communication generated before the upgrade should be treated as potentially overstated and re-derived from getTotalUsedQuota().

When to Consider This Package

Adopt when:

• The product is a Laravel application already using (or committed to) Laravel Cashier for subscriptions on Stripe or Paddle. This package assumes that foundation and is not useful without it.
• You need per-plan feature gating plus numeric quotas (seats, projects, API calls, storage units) enforced at the application layer, and you want it as configuration on existing subscription models rather than a new service.
• The team is small enough that maintaining bespoke entitlement tables and quota-increment logic is a real opportunity cost.
• Consumption is tracked at human/API-request scale inside the app — the counters live alongside your Eloquent models, not in a streaming metering pipeline.
• You're comfortable owning the upgrade cadence on a single-maintainer, niche package and pinning versions in composer.json.

Look elsewhere when:

• Billing is not Cashier-based, uses a different provider, or the roadmap points toward an external entitlement/billing platform. The integration value collapses outside the Cashier ecosystem.
• You need revenue-grade metering: high-volume event ingestion, idempotency guarantees, audit trails, and reconciliation with invoices. This package tracks usage; it does not invoice metered usage. Stripe's own metered billing or a dedicated metering vendor is the better fit.
• Entitlements must be shared across multiple services, languages, or teams — a package bound to a PHP/Laravel model is not a cross-service source of truth.
• The quota requirement is trivial (one or two boolean/limit checks). A column and a policy is cheaper than a dependency.
• You require formal SLAs, long-term support guarantees, or a vendor relationship. A community package maintained by a small team carries concentration risk that should be assessed explicitly rather than assumed away.
• You need to expose usage to customers as a contractual, financially binding figure without an internal validation layer.

How to Pitch It (Stakeholders)

To executives (1–2 sentences): Cashier Register is a low-cost Laravel library that lets us define plan features and usage limits on top of the subscription billing we already pay for, so we can launch and iterate on tiered and usage-capped pricing without building and maintaining a metering system ourselves. The 6.0.2 patch fixes a counter bug that could have shown customers inflated usage and adds a standard way to read total consumption — a correctness improvement, no migration or behavior change for users.

To engineering: It's a thin layer over Laravel Cashier — features and quotas attach to existing subscriptions via config and migrations, with no new infrastructure to run. Enforcement is explicit (canUse-style checks and usage injection) rather than implicit, so we control hard vs. soft caps. Pinning to ^6.0.2 is recommended both for the used_total correctness fix and for getTotalUsedQuota(), which should become our single read path for any user-facing usage display; avoid summing per-feature rows ad hoc. Known constraints to design around: it tracks usage but does not invoice it, it assumes Cashier/Stripe-or-Paddle, and it's a small-maintainer package — so we isolate it behind a thin internal service/adapter so swapping the metering source later is a contained change rather than a rewrite.

Risks to state plainly: single-maintainer dependency, no enterprise support, and the fact that the counter is only as correct as the code paths that increment it. Mitigate with a wrapper layer, tests around quota transitions (upgrade/downgrade/reset/over-quota), and a periodic reconciliation of getTotalUsedQuota() against source-of-truth records before any usage number is used commercially.