Laravel Exchange Rates Laravel Package

Product Decisions This Supports

• Multi-currency pricing and display: Any Laravel product that sells to international users (SaaS plans, e-commerce catalogs, marketplaces) needs an FX rate source to render local-currency prices. This package turns that from a build task into an integration task.
• Checkout, billing, and invoicing: Converting cart totals, subscription renewals, and invoice line items at a known rate, and archiving the rate used for audit/accounting purposes.
• Reporting and revenue normalization: Converting MRR, GMV, or ad spend across currencies into a single reporting currency for dashboards and finance reviews.
• Build vs. buy framing: The real decision here is about the data provider (exchangeratesapi.io), not the wrapper. The package saves roughly 1–3 engineer-days of HTTP client, config, facade, caching, and test scaffolding in Laravel; it does not save you from vendor evaluation, quota planning, or redundancy design.
• Roadmap scoping: If FX is a headline feature (pricing localization, global checkout), budget for a proper internal ExchangeRateProvider abstraction with caching, fallback providers, rounding/precision rules, and rate-lock semantics. If FX is incidental (a settings-page currency switcher), this package is a legitimate "ship it this sprint" enabler.
• Platform upgrade sequencing (new in v7.11.0): The package now drives a floor on your runtime. Adoption of v7.11.0 requires PHP 8.2+ and it is the release that unlocks Laravel 13. This makes the package a line item in PHP/Laravel upgrade planning: teams still on PHP 8.0/8.1 must either stay pinned to 7.10.x or sequence their PHP upgrade first.
• Operational decisions: Choosing cache TTLs and refresh cadence, deciding whether historical rates must be persisted locally for compliance, and defining behavior when the upstream API is down or rate-limited.

When to Consider This Package

Good fit when:

• You are on Laravel and need latest rates, historical rates, currency conversion, and supported-symbol lookups behind a familiar facade/config pattern.
• You are on PHP 8.2+ (8.0 and 8.1 were dropped in v7.11.0) — or you are willing to pin 7.10.x until you get there.
• You are on, or planning to move to, Laravel 13: v7.11.0 is the first release declaring support for it, so this is the version to adopt for a Laravel 13 upgrade.
• Your volume is low to moderate and caching rates (hourly/daily) is acceptable to the business.
• FX is a display/convenience feature, not money movement — no settlement, payouts, or trading.
• You want a small, MIT-licensed, single-purpose dependency you can read end-to-end and fork if needed.
• You are comfortable pinning the version and accepting that upstream data quality and uptime are the vendor's responsibility, not the package's.

Look elsewhere when:

• You need payment-grade or settlement-grade rates (Stripe/Wise/bank feeds), guaranteed SLAs, or regulated FX handling.
• You require high request volume, sub-minute freshness, or multi-provider failover — build a driver abstraction over several sources instead of hard-committing to one API.
• You need crypto, metals, or non-fiat instruments.
• You are outside the Laravel/PHP ecosystem, or your stack standardizes on a first-party SDK from a payments provider.
• You are stuck on PHP 8.0/8.1 and cannot upgrade this cycle — you can still use 7.10.x, but you are now on an unsupported branch with no security or Laravel-compat patches going forward.
• The single-maintainer risk (489 stars, zero listed dependents, sparse release history) is unacceptable for a tier-1 revenue path without an internal fork.

How to Pitch It (Stakeholders)

To executives: This is a tiny, free (MIT) Laravel package that lets us add multi-currency pricing and display in days instead of weeks — no license cost, no new vendor contract beyond a low-tier API plan. The v7.11.0 release is a maintenance release: it keeps us current with Laravel 13 and modern PHP, which is a positive signal on project health, but it also raises our minimum PHP version to 8.2 — a small, already-overdue infrastructure item rather than new spend. The strategic risk is unchanged: dependency on a third-party rate provider and a single-maintainer open-source project, which we mitigate by wrapping it behind our own interface, caching rates, and keeping the swap cost to a few hours. Approve it as a fast-follow enabler, not as our long-term FX platform.

To engineering: v7.11.0 is a compatibility release, not a feature release — dropping PHP 8.0/8.1, adding Laravel 13 support, and running CI on PHP 8.5. Treat the PHP floor bump as a breaking change even though the version number is a minor: if any service is still on 8.1, pin ^7.10 there and upgrade deliberately rather than letting a composer update force the runtime change. Beyond that, nothing changes architecturally: publishable config, facade, driver-style interface, and easy faking in tests. It is thin — the substance is the exchangeratesapi.io HTTP calls — so treat it as an adapter, not an architecture. Pin the version, add our own integration tests around the driver boundary, cache aggressively to stay inside API quotas, and define fallback behavior for 429/5xx responses. Worth noting the CI now exercises PHP 8.5, so forward-compat signal is decent; if FX ever becomes revenue-critical, we replace the driver, not the call sites.