Money Bundle Laravel Package

Product Decisions This Supports

• Pricing and checkout correctness. The bundle wires moneyphp/money into Symfony, so amounts are immutable value objects backed by integer minor units rather than floats. This is the decision that kills the class of bugs that show up as off-by-one-cent invoices and reconciliation noise — worth adopting the pattern even if you reject the package.
• Multi-currency roadmap. moneyphp/money ships the ISO 4217 currency table and per-currency decimal rules (JPY has 0, KWD has 3). The new v0.1.0 release adds a service definition of ISO currencies, which exposes that table as a container service — a small but real convenience for Symfony apps that want the currency list injected rather than re-declared. It moves "can we launch in Japan / the Gulf?" from an open engineering question to a formatting/rounding checklist.
• Persistence and schema design. The bundle's Doctrine DBAL type is the concrete artifact here: it commits you to storing amounts as integer minor-unit columns (plus a currency column or fixed per-row currency). That's a schema and migration decision you should make deliberately and early — changing it after you have revenue data is expensive.
• Billing mechanics: proration, refunds, splits. Allocation without losing pennies (splitting a total across N line items, partial refunds, revenue share) is a library feature, not a custom one. It supports roadmap items like partial refunds, installment plans, and marketplace payouts without bespoke rounding logic per feature.
• International UX. The form type and Twig helpers give locale-aware input/display for free, which shortens the loop on "localized price display" stories and reduces the temptation to hand-roll currency strings in templates.
• Build vs. buy (really: buy vs. vendor). This package is thin glue — a DBAL type, a form type, a Twig extension, a currency service definition, config for default currency and decimal places. A PM should price it as "a few hundred lines we don't write" rather than as a platform dependency. Adopting it is cheap; the decision worth escalating is whether you depend on it or copy the pattern in-house.

When to Consider This Package

Consider it when:

• You are on a Symfony application using Doctrine ORM/DBAL — this is a Symfony bundle, not a Laravel package. If the codebase is Laravel, the package is not usable as-is; take moneyphp/money directly with custom Eloquent casts, or evaluate a Laravel-native alternative.
• The team has already standardised on moneyphp/money and wants the Doctrine/Form/Twig/DI integration without writing glue — the v0.1.0 currency service definition is a minor argument in favour of the integration layer.
• You want the ISO currency table available as an injected service rather than hard-coded or fetched ad hoc.
• The surface area is modest — internal tooling, admin panels, back-office invoicing — where a young or slow-moving dependency is a nuisance rather than a revenue risk.
• You want the pattern more than the package: read the source, lift the DBAL type, and own it.

Look elsewhere when:

• You need a track record. v0.1.0 is a first release — a fresh start, but pre-1.0 with a minimal surface (one service definition added). It resets the "stale since 2020" concern, but it does not yet establish maintenance cadence, backward-compatibility policy, or a community backstop. Treat Symfony/PHP compatibility as unverified until someone on the team proves it in a spike.
• Money is on a revenue-critical or compliance-critical path with an expectation of security patching and version support. A 0.x package is a fork-and-own commitment, not a settled adoption.
• You need currency conversion or exchange rates — out of scope for both the bundle and the underlying library; you need a rates provider and a conversion policy decision separately.
• You need non-ISO units (crypto, loyalty points, usage credits) — the ISO-centric model fights you.
• You need locale formatting beyond what intl gives you, or custom rounding/tax rules per jurisdiction (e.g., round-half-up vs. banker's rounding, VAT-inclusive pricing display). These are product rules the library won't decide for you.

PM framing: the honest read is "good pattern, thin and early-stage package." The v0.1.0 release revives the wrapper and confirms it is Symfony-DI-oriented, but one service definition does not change the risk profile. Score and adoption signals still say vendor or reimplement the glue, adopt the underlying library's semantics.

How to Pitch It (Stakeholders)

To executives: We have a recurring class of money defects — rounding drift, misformatted prices in new markets, penny loss when splitting or refunding. The fix is a standard representation of money (integer minor units, immutable value objects) rather than per-feature arithmetic. The underlying library is mature. The Symfony integration layer we're evaluating just published its first release (v0.1.0), which is encouraging but is a fresh start — it is pre-1.0, lightly used, and has no support commitments yet. Recommendation: adopt the money model as a standard, and plan to own a small amount of integration code rather than depend on a young package. Cost is low either way; the decision that matters is committing to the representation now, before schema and revenue data accumulate.

To engineering: This is a Symfony bundle wrapping moneyphp/money — a Doctrine DBAL type for persisting amounts, a Form type, Twig helpers, and now a container service definition for the ISO currency table. The wrapper is ~glue; the value is the underlying library and the discipline of integer minor units. The v0.1.0 release means the "unmaintained since 2020" concern is no longer the framing — the new concern is maturity and cadence. Expect to verify PHP/Symfony compatibility, and budget for vendoring the DBAL type (~a few hundred lines) so we're never blocked by a 0.x release. If we're on Laravel, skip the bundle entirely and use the base library with custom casts. Open questions we need answered in a spike: current framework version compatibility, how we store currency alongside amounts, whether the new currency service is worth wiring versus injecting our own table, and rounding policy per market.