Weave Code
Laravel Money Laravel Package
finller/laravel-money
Laravel Money offers a convenient Money value object for Laravel apps, with Eloquent casts, currency-aware arithmetic, and formatting helpers so you can store, calculate, and display monetary values safely without floating-point errors.
Brick/Money for Laravel. Parse, Cast and Validate.
Frequently asked questions about Laravel Money
- What is finller/laravel-money and what does it actually do?
- It is a thin Laravel adapter around Brick/Money that provides a Money value object plus Eloquent casts, validation rules, and parsing helpers. It handles currency-aware arithmetic and formatting so you avoid floating-point rounding errors in your application code. It is not a ledger or accounting engine; treat it as the boundary layer where HTTP input, model attributes, and display output meet.
- How do I install and configure finller/laravel-money in a Laravel app?
- Install it with composer require finller/laravel-money, and the service provider is picked up automatically through Laravel package discovery on supported versions. Check the README for any optional config publishing step if you need to change currency or formatting defaults. Verify that discovery works in your CI pipeline rather than assuming it does on older Laravel releases.
- Which Laravel, PHP, and Brick/Money versions are supported?
- The support matrix is not widely documented, so inspect the package's composer.json constraints and CI matrix before adopting it. Pin explicit Laravel, PHP, and brick/money constraints in your root composer.json to avoid surprise upgrades. Run your existing test suite against the cast and validation behavior on your exact framework version before merging.
- How should I persist money values in the database when using this package?
- Store integer minor units, such as cents, in a dedicated column alongside a separate ISO 4217 currency code column. Use the Eloquent cast to convert between those stored integers and Money objects at the model boundary. Write an architecture decision record covering storage format and rounding policy before rolling the pattern out to more than one model.
- Does laravel-money support multi-currency values and exchange rates?
- It supports currency-aware values through Brick/Money, but it is not an exchange-rate or conversion service, so any rate logic is yours to provide. Matching a stored amount to its currency column is your responsibility to validate. For multi-currency reporting, keep exchange rates in your own domain layer rather than inside a cast.
- How are null, zero, negative, and invalid currency inputs handled?
- Behavior for nullable columns, zero amounts, and negative values depends on your cast configuration and Brick/Money's parsing, so cover each case with tests. Invalid or unknown currency codes should fail through the provided validation rules rather than silently defaulting to something. Test locale-formatted strings like 1.234,56 and 1,234.56 explicitly, because ambiguous parsing is a real risk.
- Is finller/laravel-money suitable for payments, accounting, or financial ledgers?
- No, it is an adapter for parsing, casting, and validating, not a system of record. If you need double-entry bookkeeping, reconciliation, or regulatory correctness, use a dedicated ledger and apply this package only at the edges. Treat it as a convenience layer over Brick/Money rather than a source of accounting truth.
- Can I use it alongside moneyphp/money or my existing custom money cast?
- Running two money abstractions in one codebase becomes confusing quickly, so only adopt it if you will standardize or wrap it behind an adapter interface. If you already use moneyphp/money, keep it unless this package removes real duplication. If you do migrate, move reads first, then writes, then validation rules.
- How actively maintained is laravel-money, and what is the adoption risk?
- It is an MIT-licensed package with a small surface area but limited adoption, roughly 19 GitHub stars and a narrow maintainer base, so bus-factor risk is real. Recent releases are a positive signal but do not substitute for broad ecosystem validation. Pin versions, run composer audit, enable automated dependency updates, and consider an internal wrapper so replacement stays cheap.
- How should I test money handling before shipping this package to production?
- Write feature tests covering casting on save and load, validation on form requests, formatting output, and round-tripping through your API. Include edge cases such as null, zero, negative, very large amounts, invalid currency codes, and locale-formatted input strings. Also assert that serialized responses expose integer minor units plus a currency code, never a raw serialized Money object.
Weaver
How can I help you explore Laravel packages today?