Exchanger Laravel Package

Product Decisions This Supports

• Multi-currency pricing and checkout. Any decision to sell, price, or quote in more than one currency needs a rate source. This package supplies the rate; your application still owns rounding, markup/spread, display formatting, and price-locking rules — so it unblocks the feature without dictating the commercial policy.
• Market expansion roadmap. Because 30+ providers sit behind one ExchangeRateService interface, "can we support GEL/UAH/TRY/BYN/crypto?" becomes a configuration and vendor question rather than an engineering project. That makes new-market sizing cheaper to evaluate.
• Build vs. buy on FX plumbing. The default engineering instinct is to hand-roll a client against whichever FX API marketing saw first. That work is undifferentiated: HTTP clients, retries, currency-pair normalization, cache keys, and per-vendor quirks. Adopting a provider layer (MIT, no license cost, maintained since 2016) removes that build from the roadmap and converts it into a dependency to govern.
• Vendor-risk reduction / procurement leverage. Chain fallback plus 10+ free central-bank providers means you are not married to one vendor. That is directly useful in renewal negotiations: you can credibly demonstrate a working fallback rather than threaten one.
• Unit-cost control for rate lookups. PSR-16 caching and per-query options let you trade freshness against API call volume, which is the main cost driver on paid tiers. Relevant to any decision about whether to pay for a tier or absorb free-tier limits.
• Historical rate backfill for finance/reporting. Historical queries support restating past invoices, revenue normalization, and period-close reporting — decisions that are painful to reverse if the underlying data was never captured.
• Framework integration strategy. This is the provider layer beneath Swap and Laravel Swap. Choosing to consume it directly is a deliberate decision to own chain composition, cache key strategy, and HTTP middleware (rate limiting, observability, request signing) — appropriate for a platform team, not for a feature team.
• Do not treat it as a product differentiator. It is infrastructure. It should appear in architecture and procurement decisions, not in positioning or customer-facing roadmap narratives.

When to Consider This Package

Adopt it when most of the following hold:

• You need programmatic FX rates in PHP 8.2+ and expect to support multiple currency pairs, not one hardcoded pair.
• You want resilience: a primary commercial provider with a free central-bank or public fallback, plus explicit ChainException handling when all providers fail (so you can degrade gracefully at checkout rather than 500).
• You need historical rates for reporting, refunds, or reconciliation, and want that from the same interface as live rates.
• You need control the higher-level libraries don't expose: custom chain ordering, a specific cache-key/namespace scheme, or HTTP middleware for signing, rate limiting, or tracing.
• You are building a reusable internal FX service or a framework binding that isn't Swap/Laravel Swap.
• You have an owner who will manage API keys, provider deprecations, and endpoint changes — this is the real ongoing cost, not the initial integration.

Look elsewhere when:

• You are building a standard Laravel app. Use florianv/laravel-swap (Swap → Exchanger). It gives you defaults, config publishing, and a builder API; going one layer down buys you flexibility you probably won't use and support burden you will. Only go direct if you have a specific reason.
• You need contractual or settlement-grade rates. Provider rates are indicative. Accounting, revenue recognition, or customer-refund calculations at material scale need a treasury/bank feed or a licensed data vendor with SLAs and audit trails.
• You need high-frequency or streaming data. This is request/response with PSR-16 caching. No tick streams, no websockets, no intraday granularity guarantees.
• Your only need is one pair, one source, low volume. A thin client against a single vendor is simpler and has fewer moving parts than a 30-provider abstraction.
• You cannot accept provider-API churn. The changelog is instructive: Yahoo and Google integrations were removed outright; the National Bank of Romania endpoints had to be repointed. 30+ providers is coverage, but also 30+ surfaces that can break. If nobody can triage "the PLN rate stopped working," this becomes a latent checkout outage.
• Small-team/low-appetite signals worry you. 185 stars and 0 listed dependents in this dataset suggest a narrow adoption base — first verify it's arriving transitively via Swap/laravel-swap, which changes the support calculus considerably. Also note the README's recommended default service is the project sponsor (fastFOREX); there's no lock-in, but treat the default as a marketing-suggested starting point, not an endorsement.

How to Pitch It (Stakeholders)

To executives: This is free, MIT-licensed plumbing for currency conversion that has been maintained for roughly a decade. It gives us one integration point to more than 30 rate sources — including free central banks — with automatic failover and caching. The business case is speed and risk, not savings on a line item: it lets us price in new markets without new engineering work, and it lets us switch FX vendors without a code change, which is real leverage at renewal time. Costs are engineering integration (small), one paid provider tier (order of $20–50/month, avoidable at low volume), and ongoing ownership of credentials and vendor changes. The risk is that provider APIs drift; our mitigation is the fallback chain plus a named owner.

To engineering: Treat this as the provider layer, not the API. If you're in Laravel, consume it through Laravel Swap unless you can articulate why you need direct control of chain composition, cache keys, or HTTP middleware — that's the only justification for the extra surface area. It's PHP 8.2+, PSR-18 HTTP, PSR-16 cache, and returns rates as floats with provider name and date attached. The package fetches the rate; we own the conversion math, rounding, spread, and the failure mode at checkout when a ChainException is thrown. Budget for: primary provider key management, a documented fallback (ECB is EUR-base only), cache TTLs aligned to business tolerance, and monitoring on provider error rates. Verify current adoption and transitive usage before we commit — the visible dependent count is low, so let's confirm who else depends on this before we're the only ones who notice when it breaks.