Open Exchange Rates Bundle Laravel Package

Product Decisions This Supports

• Whether to offer multi-currency pricing / display. The underlying need this package nominally serves — showing prices, invoices, or reports in a user's local currency — is a real product decision. If you're evaluating multi-currency checkout, localized price display, or FX-adjusted reporting, this is the class of dependency you'd need.
• Build vs. buy for the FX data layer. The package itself is a ~100-line Symfony2 service wrapper around the OpenExchangeRates HTTP API. The actual "buy" decision is the OpenExchangeRates subscription (free tier is USD-base-only and rate-limited; paid tiers unlock arbitrary base currencies, historical data, and time-series endpoints). The wrapper is trivially replaceable; the data contract is not.
• Roadmap scoping for FX-dependent features. Any feature that needs a daily reference rate — revenue normalization across regions, "approx. $X" price hints, dunning/refund amounts in local currency — can be scoped as a small internal service. The existence of a (stale) wrapper should not inflate the estimate.
• Architecture/stack fit. This is a Symfony 2 bundle, not a Laravel package. It registers as a bundle in AppKernel, ships a DI extension, and depends on Symfony2-era components. Adopting it implies a decision to remain on (or support) a legacy Symfony 2 codebase, which is itself a product-risk decision.
• Not a fit for: settlement, accounting-grade revenue recognition, or anything requiring audited historical rates. FX for financial postings needs a sourced, versioned, auditable rate provider — not a thin client with no rate persistence.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining an existing Symfony 2.x application (2.8 at the latest — EOL since November 2018) and cannot add modern HTTP tooling.
• You already have an OpenExchangeRates API key and are comfortable with that provider's pricing, rate limits, and USD-base free tier.
• You need nothing more than latest.json-style spot rates for display purposes.
• You accept the maintenance burden of a dependency with 9 stars, 0 dependents, and no release since December 2017 — effectively unmaintained for ~7 years.

Look elsewhere in every other case:

• Laravel / modern Symfony (5/6/7): the bundle will not install or boot. Use Illuminate\Support\Facades\Http or Symfony's HttpClient and call the API directly — it's a handful of lines.
• You want maintained FX plumbing: use moneyphp/money or brick/money for the value-object/rounding side, plus a small first-party rate fetcher with caching and a persisted rate table. Provider alternatives worth comparing: exchangerate.host (free, no key), Frankfurter (ECB data, free), OpenExchangeRates paid tiers.
• You need historical or time-series rates: the free/legacy API surface this bundle wraps won't cover it; go straight to a paid provider with a documented history endpoint.
• You need reliability guarantees: no tests, no CI, no security policy, no changelog. Assume it breaks silently on any upstream API change.

How to Pitch It (Stakeholders)

Bottom line: do not adopt this package. Re-implement the ~50 lines it saves.

For executives: The capability we actually care about — multi-currency pricing and FX-normalized reporting — is still viable and cheap. But this specific library is a 2017 wrapper for a Symfony 2 framework that reached end-of-life in 2018, with no releases, no maintainers, and zero downstream users. Pinning it into our codebase imports an unpatched liability into anything touching pricing and money. The cost of replacing it with our own small, tested client is measured in hours, not sprints.

For engineering: Treat this as a reference implementation, not a dependency. It tells you what the OpenExchangeRates response shape looks like and roughly how to wire a service. Rebuild it as a first-party class: injectable HTTP client, response caching with a TTL that matches the provider's refresh cadence, a persisted exchange_rates table keyed by (base, quote, date), explicit decimal handling via brick/money or moneyphp/money, and a fallback/stale-rate policy. That gives us testability, auditability, and a swap path to another provider without touching product code.

Risk if we proceed anyway: abandoned dependency, EOL framework, no security response path, and silent breakage on provider API changes — on the one code path where being wrong costs real money.