Laravel Money Laravel Package

Product Decisions This Supports

• Storage and schema strategy for money. Forces an explicit choice between integer minor units, DECIMAL, and string columns — and enforces it everywhere via casts, so pricing decisions (sub-cent metering, 8-decimal FX rates, per-unit pricing) aren't quietly blocked by the database.
• Pricing, packaging, and geo-expansion. Multi-currency price lists, regional rounding conventions, and discount/tax ordering can be modeled with declared rounding strategies instead of ad hoc float math. Launching in a new market becomes a configuration and validation exercise rather than a refactor.
• Public API and data contracts. Standardizes how money crosses boundaries (amount + currency, never a bare number), which directly affects API stability, partner integrations, and export formats.
• Build vs. buy. Building a cast plus validator is roughly one to two dev-days. The edge cases — locale-aware parsing, precision, rounding modes, currency validation — are where that estimate quietly triples. Buying a thin wrapper over a mature foundation trades a small dependency for correctness.
• Risk scoping in high-consequence flows. Checkout totals, proration, refunds, payouts, invoicing, and accounting exports are where off-by-a-cent bugs become finance tickets and audit findings. This package is most defensible when applied to those paths first.
• Roadmap sequencing. If multi-currency or metered billing is on the horizon, adopting the primitive now is cheaper than retrofitting it after the schema has calcified.

When to Consider This Package

Adopt when:

• You're on a modern Laravel version and either support or plan to support more than one currency.
• You need precision beyond integer cents — metered usage, crypto, FX, or tiered per-unit pricing.
• You want money handled at the boundaries (request validation, Eloquent casts, API resources) without owning and maintaining that glue.
• You value a small, auditable surface area: a thin wrapper is easier to read, fork, or vendor than a framework of its own.

Look elsewhere, or proceed deliberately, when:

• You're single-currency with whole-cent amounts. An integer cents column and one accessor is sufficient; the dependency isn't earning its keep.
• You've already standardized on moneyphp/money or brick/money directly. A wrapper adds indirection your team may not want.
• You need vendor SLAs, long-term support, or a broad community to answer questions. 19 stars is a real signal — minimal ecosystem, thin Q&A coverage, and single-maintainer risk. Treat it as a small internal-quality dependency, not a strategic platform bet.
• You require serious treasury/FX capability. Brick's exchange-rate providers are basic; you'll need your own rate service regardless.
• Non-PHP services in the stack consume the same data. The value here is Laravel-specific glue, so cross-language consistency has to be solved separately.

Mitigations if adopting: pin the version, wrap usage behind your own Money value object or service so the package name never appears in domain code, add characterization tests around rounding and serialization, and verify issue responsiveness and release cadence before committing.

How to Pitch It (Stakeholders)

For executives: Money bugs are expensive and public. Wrong totals, rounding drift, and currency mix-ups in checkout or invoices turn into refunds, support volume, and audit findings. This package standardizes how we parse, store, and validate monetary values, which removes a whole class of correctness incidents and shortens the path to launching in new currencies. Cost is effectively zero — MIT licensed, thin wrapper — and the primary risk, that it's a small open-source project, is contained by putting our own interface in front of it so we can swap it out without touching product code.

For engineering: It's idiomatic Laravel glue over Brick/Money — Eloquent casts, validation rules, and parsing — so we delete hand-rolled float handling and get arbitrary precision, ISO currency handling, and explicit rounding for free. The API surface is small and readable, and forking is realistic if maintenance stalls. Recommended path: a one-day spike on our highest-risk money path (checkout totals or invoice generation), adopt behind an internal abstraction, pin the version, and cover rounding and serialization with tests before broad rollout.