Cashier Laravel Package

Technical Evaluation

What this package actually is. andrey-helldar/cashier is not Laravel Cashier. It is a read-only subtree split of the cashbox/foundation monorepo — the split exists so a subpackage can be installed independently via Composer, not because it is a standalone product. Source of truth, issue tracker, and history live upstream in the monorepo; this repository is a publishing artifact. The archived status (last release 2023-07-09) confirms upstream has stopped cutting splits or the split was retired.

Documentation integrity is the first risk. The supplied description.md describes "Cashier-style helpers" and cashier workflows, and assessment-laravel_dev.md describes provider credentials, webhook signature verification, and a Billable trait — that guidance is written for a different package (cashier-provider/core, i.e. real Laravel Cashier billing). Neither describes a currency/money-formatting subtree split. Do not treat these artifacts as an integration spec; the only reliable documentation is the vendor source after composer require.

Architecture fit. Reasonable only if the requirement is narrow: currency formatting, money helpers, and number/unit conversion utilities inside a Laravel app already on the era-appropriate framework version. It is a poor fit for anything touching billing state, subscription lifecycle, webhooks, or persisted monetary values — that is not what this package does, and the name collision with laravel/cashier will actively mislead engineers and reviewers.

Integration feasibility. Low technical effort, high validation effort. Service provider and facade follow standard Laravel package conventions (auto-discovery, publishable config), so wiring it up is trivial. Validating that it is safe — correct version constraints, no abandoned transitive dependencies, no facade alias collision with laravel/cashier — requires reading composer.json and source directly.

Technical risk. High. Bus factor of one, 9 stars, no upstream support, no security-advisory pipeline, no roadmap, no guarantee of Laravel 10/11/12 or PHP 8.2+ compatibility. Subtree-split tags can diverge from monorepo tags, so version pinning semantics are weaker than they look. The composite score of 0.1875 reflects this. This is a dependency you would be adopting and owning.

Key questions to resolve before proceeding:

• Is the actual requirement money/currency formatting, or billing/subscriptions? If the latter, this is the wrong package and the assessment must be restarted against laravel/cashier.
• Is the upstream cashbox/foundation monorepo still active and receiving framework-compatibility updates? If so, depend on the monorepo, not the split.
• Which Laravel and PHP versions are in scope, and does the package's own constraint set cover them?
• Are formatted amounts used purely for display, or do they feed invoices, persistence, or reconciliation? Any answer other than "display only" raises the risk tier.
• Can a first-party adapter (brick/money, moneyphp/money, or intl) cover the same need with a maintained dependency?

Integration Approach

Stack fit. Assume a Laravel 8/9 and PHP 7.4–8.1 vintage until proven otherwise. Verify composer.json constraints against the target application before any code is written. If the application is on Laravel 10+, treat compatibility as unproven and plan for a fork-and-patch outcome.

Migration path. Do not depend on the split directly. Two preferred paths, in order: (1) depend on cashbox/foundation upstream if it is maintained; (2) wrap the package behind an internal MoneyFormatter interface with a one-file implementation, so swapping to brick/money later is a contained change. Never let package types leak into domain models, DTOs, or database columns.

Compatibility checks. Pin an exact version, commit the lock file, run composer why and composer outdated. Explicitly confirm no facade alias or config-key collision with laravel/cashier. Re-publish and diff config after any bump. Run php artisan config:clear && route:clear && cache:clear in the deploy script — cached config will happily serve the previous stub.

Sequencing.

1. Two-hour spike in a throwaway branch: install, inspect composer.json, list public classes, read the service provider.
2. Confirm the actual API surface from source and write a one-page internal note replacing the misleading provided docs.
3. Build the adapter interface with unit tests locked to known-good locale/currency cases, including zero-decimal (JPY) and three-decimal (BHD) currencies.
4. Integrate into a low-blast-radius surface first — view/PDF formatting — not into persistence or anything a customer is billed from.
5. Decide on fork-vs-adopt and record the decision with an owner and review date.
6. Only then expand usage. Store money as integer minor units yourself regardless; never as floats and never via the package's own storage assumptions.

Operational Impact

Maintenance. Effectively zero upstream. An archived package means we own every future patch, framework bump, and CVE response. Budget explicitly for a fork (or a documented adapter swap), assign a named owner, and add a Renovate/Dependabot watch so a silent break is discovered in CI rather than in production.

Support. No upstream maintainer engagement, no issue triage, and a community of single-digit stars — assume no external help. Internal runbook and a "why we forked this" note are mandatory; otherwise the next engineer will assume it is Laravel Cashier and integrate it into the billing path, which is the highest-severity failure mode here.

Scaling. Runtime cost is negligible — these are pure formatting helpers. The scaling risk is organisational, not technical: every additional service that depends on the split multiplies the fork burden. Keep the dependency to one service, or better, one shared internal package.

Failure modes to design against:

• Identity confusion: a developer installs or uses this expecting subscription billing. Mitigate with naming discipline in docs and code (MoneyFormatter, not Cashier).
• Silent formatting drift: locale or currency-table changes alter displayed amounts without tests noticing. Lock output with golden-file tests.
• Framework upgrade breakage: no upstream patch means a Laravel bump can strand the package mid-upgrade. Adapter boundary is the mitigation.
• Stale vendored copy: a fork patched once and never rebased. Record the base commit and add a quarterly review.
• Composer resolution to an abandoned tag set: pin exact versions and commit the lock file.

Ramp-up. Low for consumers — a day for an engineer to learn the API once it is documented internally. Medium for an owner — roughly 1–2 days to fork, isolate, and instrument. The larger cost is organisational education: correcting the misconception created by the package name and the provided (mismatched) documentation. Overall recommendation as TPM: do not adopt into a critical or money-authoritative path; approve only as a display-formatting helper behind an adapter, with an explicit fork owner and a scheduled exit review.