Laravel Currency Laravel Package

Product Decisions This Supports

• Multi-currency pricing display (build vs. buy): Decides whether to ship a currency switcher / localized price display using an off-the-shelf Laravel wrapper versus building an FX abstraction layer in-house. Concretely: catalog prices, plan pricing pages, and invoice previews rendered in the buyer's local currency.
• MVP scoping for international launch: Lets you validate demand for localized pricing in a new market before committing engineering time to a maintained FX vendor, contract, or internal service.
• Roadmap sequencing for "international" epics: Provides a cheap probe to learn which currencies customers actually select, which informs whether the next investment is FX accuracy, tax/VAT localization, or payment-method localization.
• Crypto rate display as a feature experiment: Supports a low-cost test of showing BTC/ETH reference rates alongside fiat (e.g., "price in USD, settle in crypto") without standing up a separate market-data integration.
• Historical rate needs for reporting/analytics: Informs whether finance dashboards need stored, point-in-time rates (audit-friendly) versus live display-only conversion — two very different product commitments.
• Maintenance/total-cost-of-ownership decisions: The archived status (last release Feb 2023) and dependence on a third-party free API turn this into a deliberate "accept dependency risk" call rather than a neutral library choice.
• Deprecation and migration planning: If already in the codebase, this assessment supports a decision to fork, wrap, or replace — and to size the work.

When to Consider This Package

Consider it when all of the following hold:

• The consuming app is Laravel/PHP and the team wants a same-framework integration with minimal setup (config publish, facade, a couple of methods for latest/historical rates).
• Rates are display-only and non-binding — "approximately €42" on a marketing page, not a legally binding quote or a settled transaction amount.
• Traffic and call volume are low enough that a single upstream free API plus application-level caching is acceptable, and you can tolerate a stale-or-missing rate falling back to a base currency.
• You need a fast proof of concept (days, not sprints) and are comfortable treating the library as a reference implementation or fork candidate given the MIT license.
• Crypto coverage is a nice-to-have experiment, not a product-critical feed.

Look elsewhere when any of these are true:

• You need a maintained dependency. The repo is archived and has had no release since 2023-02-17; no security patches, no Laravel-version compatibility guarantees, no upstream bug fixes. For a multi-year product surface, plan to vendor/fork it or pick an actively maintained SDK.
• Upstream API terms are unverified. It is built on exchangerate.host's free tier; free-tier terms, keys, and rate limits have changed over time. Confirm current pricing, authentication requirements, attribution rules, and commercial-use terms before it appears in a customer-facing feature. If the answer is "requires a paid plan and key management," the package's convenience advantage shrinks considerably.
• Accuracy, SLAs, or auditability matter. No uptime commitment, no SLA, no reconciliation, no guaranteed source-of-truth. Pricing, invoicing, refunds, revenue recognition, and anything a finance team signs off on need a contracted provider and persisted, timestamped rates.
• You need compliance or regulated handling (FX disclosure, rounding rules, tax conversion, PCI-adjacent checkout flows) — the library does conversion, not policy.
• You expect high volume or many currencies per request. Rate limiting, batching, and cache-invalidation strategy become your problem; a wrapper around one free endpoint is not a rate infrastructure.
• You need resilience engineering (failover providers, circuit breakers, multiple sources cross-checked) or real-time/tick-level crypto data.

Adoption gate I'd apply: a one-day spike behind a feature flag, with a documented fallback path, a named owner, and an explicit "replace by" trigger (e.g., first paying customer in a non-base currency, or first finance dependency).

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, MIT-licensed Laravel package that fetches current and historical fiat and crypto exchange rates from a public API and makes them available in a few lines of code. It's a genuinely cheap way to test whether localized pricing moves conversion in a new market — days of effort, no contract, no vendor negotiation. The catch is that it's archived (no updates since February 2023) and entirely dependent on a third-party free API whose terms have shifted over time. So the right framing is "low-cost experiment, not platform infrastructure": use it to buy information about demand, with a pre-agreed exit criterion and a small budget reserved for replacing it with a supported provider or an internal FX service before any revenue-critical or finance-facing use. Do not let it silently become the pricing backbone.

To engineering: Treat it as a thin wrapper worth forking rather than adopting as a dependency. Isolate it behind our own ExchangeRateProvider interface so swapping to a maintained SDK, a paid provider, or cached internal rates is a one-class change. Requirements to accept: aggressive caching with TTL and a documented staleness policy, explicit fallback to base currency, no calls in the request path of checkout or invoice generation, a metric on upstream failures, and a ticket to revisit once we validate the use case. If we keep it, we own it — pin the version, vendor the code, and assign an owner for the upstream API contract.

Ask: approve a timeboxed spike behind a flag; revisit in one quarter with usage data and a build-vs-buy recommendation.