Currency Exchange Bundle Laravel Package

Product Decisions This Supports

• Multi-currency pricing and display — deciding whether catalog, cart, and checkout can show localized prices (EUR/USD/GBP) rather than a single base currency.
• Geographic expansion sequencing — currency support is usually a hard prerequisite for launching in a new market; this package's domain is the "can we price locally?" question on the roadmap.
• Build vs. buy for a commodity capability — currency conversion is a well-understood, low-differentiation service. This package sits at the "thin dependency" end of the spectrum, which is useful mainly as a reference point for scoping the real build-vs-buy decision (provider SDK vs. in-house adapter vs. full FX platform).
• Finance and reporting consolidation — normalizing revenue, refunds, and payouts across currencies at consistent rates; the package's rate-provider abstraction and its dated-currency persistence hint at the data model (rate source, timestamp, base/quote pair, effective date) a finance dashboard needs.
• Checkout and refund policy — whether to lock a rate at order time and which historical rate to use for refunds; a decision that must be made explicitly and is not solved by a rate fetcher whose historical-date handling only just received a bug fix.
• Use cases it maps to: B2B invoicing in local currency, marketplace seller payouts, subscription plans priced per region, and multi-currency reporting.

Decisions it does not support well: real-time or intraday pricing, rate locking with SLAs, crypto or exotic pairs, audit-grade historical rate reconciliation, or anything requiring a maintained security posture. The v2.0.6 hotfix (saving currencies with past date, #70) reinforces the last point: writing historical rates correctly was broken until this patch, which is precisely the operation a refund/reconciliation workflow depends on.

When to Consider This Package

Only in a narrow legacy context:

• You are on Symfony 2.x/3.x — note this is an ONGR Symfony bundle, not a Laravel package. In a Laravel codebase the service container, config, and DI wiring do not carry over; you would be porting, not installing. v2.0.6 does not change this: it is a patch-level hotfix with no framework, container, or PHP-version modernization.
• You already run the ONGR stack (Elasticsearch bundles) and want a consistent vendor surface.
• Daily/static rates from a single provider are acceptable, and you are prepared to fork and maintain the code yourself.
• You need a reference implementation of the domain model (provider interface, conversion service, dated currency records) to copy rather than depend on.

Look elsewhere when:

• You are on PHP 8+, Laravel, or Symfony 5/6+ — the release line remains a 2.x branch from the 2016 era. v2.0.6 is a single bug fix, not evidence of renewed platform support, so Composer resolution against modern PHP and framework constraints will still likely fail outright.
• Supply-chain review matters: 3 stars, 0 dependents, and a multi-year dormancy interrupted only by one isolated patch still reads as effectively unmaintained upstream. There is no visible security response path, no CI signal in the release note, and no dependency or PHP-version refresh.
• You need real-time rates, provider failover, rate-lock tables, historical audit trails, or an SLA — none of which a single-provider bundle provides.
• Compliance or finance stakeholders require documented rate provenance. A patch fixing past-date persistence tells you the historical path was recently incorrect, not that it is now audited.

Recommended substitutes: a maintained provider client (ECB reference feed, exchangerate.host, OpenExchangeRates, Fixer) behind a thin internal ExchangeRateService interface, plus your own cached rate table with an explicit effective_date column. That is roughly a one-to-two-day engineering effort and removes the dependency risk entirely.

How to Pitch It (Stakeholders)

To executives: Currency conversion is a commodity capability — it is not where we differentiate, but it is a gate on entering new markets. The high opportunity score attached to this package reflects the value of the problem space, not the quality of the code. A new patch (v2.0.6) appeared after a long dormancy, but it is a single hotfix for saving currencies with past dates — no new capability, no platform modernization, still negligible adoption. Recommendation stands: do not adopt; fund a small, owned adapter over a commercial or central-bank rate feed. Cost is measured in days, not sprints, and it eliminates a long-term maintenance and security liability.

To engineering: The v2.0.6 change is a one-line-class fix to the dated-currency persistence path (#70). It is not a reason to reconsider the dependency: the project is still a Symfony bundle (not Laravel), still on a 2016-era 2.x line, and the patch carries no PHP 8, framework, or dependency upgrades. Treat it as a design reference only: borrow the provider-interface and conversion-service shape, note that it models effective-dated currencies, then implement against a current SDK with caching, a persisted rate table keyed by date, and explicit rate-lock semantics at order time. Estimated effort: 1–2 engineer-days for parity, plus a short design note on refund/historical-rate policy. The fact that historical-date saving needed a hotfix is a useful argument for owning our own effective_date handling with tests.

To finance and legal: We will own the rate source, its timestamp, and the audit trail — which is what we want, because "which rate did we use and when" is a question this package cannot answer to an auditor's satisfaction. The latest release is a bug fix for recording past-dated currencies, which is exactly the operation our refund and reconciliation reporting depends on; we should not build an audit narrative on top of a codebase whose historical path is only now receiving corrections.