- How do I install mgcodeur/laravel-currency-converter in a Laravel app?
- Run composer require mgcodeur/laravel-currency-converter and Laravel's package auto-discovery registers the service provider and facade for you. Publish the config file with php artisan vendor:publish so you can adjust provider settings per environment. There is no bootstrapping friction beyond that, and the whole integration is realistically a half-day spike for a mid-level engineer rather than a sprint item.
- Does laravel-currency-converter really work without an API key?
- Yes, the package advertises currency conversion with no API key required, which removes secrets management, key rotation and per-environment provisioning entirely. That is a genuine accelerant for prototypes, internal tooling and display-only conversions. The trade-off is that no key usually means no account, no quota, no contract and no SLA, so verify the rate provenance from source before relying on it commercially.
- Which Laravel and PHP versions does this currency converter support?
- It is a thin, native Laravel utility (service provider plus facade plus config) targeting Laravel 9 through 12 on PHP 8.1 and above. Auto-discovery means it drops into existing projects with no structural changes and works in HTTP requests, queue workers and scheduled commands. Pin the version in composer.json, since a low-star package from a single maintainer warrants conservative version constraints.
- How do I convert currencies with the package's facade?
- You call the facade to convert an amount from one currency to another and to fetch the current exchange rate for a pair. Keep those calls in your service layer or an infrastructure adapter rather than inside domain models, because the package answers what the rate is right now, not what an order is worth. That placement keeps the vendor dependency swappable and your business rules testable.
- Where do the exchange rates come from and how fresh are they?
- The description does not document the rate source, so you must read the source to determine whether rates are a bundled static JSON snapshot or fetched from a free public endpoint. A static snapshot decays the moment the release ages, which is harmless for approximate display but dangerous for pricing. A free endpoint shifts availability, per-IP throttling and terms-of-use onto you, and neither mode is documented as an SLA.
- Does the package cache exchange rates and can I configure the TTL?
- Check whether the package caches internally, whether the TTL is configurable and whether it uses the default Laravel cache store; the config file published via vendor:publish is where those settings would live. If caching is thin or absent, wrap conversions in your own Cache::remember with a short TTL, especially on high-traffic pages. Avoid triggering a conversion on every page render, since that turns a rate lookup into a latency source.
- Can I get historical or as-of exchange rates for invoices and refunds?
- The package is oriented around current rates, and historical or as-of rate support is not documented, so treat it as unavailable unless the source proves otherwise. Reconciliation, refunds and month-end reporting need the rate as of the transaction date, which means you should persist the applied rate on your own records at write time. That single habit protects you from later rate drift and audit questions.
- How are rounding and currency minor units handled?
- Before using it for anything transactional, verify from source how ISO 4217 minor units are treated (JPY has 0 decimals, KWD has 3), whether the math uses bcmath or string arithmetic, and whether the rounding mode is configurable. The package is a rate source, not a money library, and float drift shows up as cent-level mismatches in aggregates that are expensive to unwind. Pair it with brick/money or moneyphp/money for arithmetic on any amount that reaches an invoice.
- What happens if the rate provider is unreachable or a currency pair is unsupported?
- You need to determine whether an unreachable upstream throws an exception, silently returns a stale value, or falls back to a cached last-known-good rate, and whether the package makes any network calls during service provider boot. Unsupported pair behavior must also be confirmed so you can fail gracefully instead of displaying a wrong price. Wrap conversions in try/catch, log failures, and have a defined fallback for checkout and pricing paths.
- Is it safe for production billing or should I use something else?
- For display-only conversions, prototypes and internal tooling it is a perfectly reasonable, MIT-licensed utility. For billing, invoicing or payments, bind it behind your own CurrencyRateProvider interface from day one, use a money library for arithmetic, and capture the applied rate and its source on every transaction. With roughly 53 stars and a single maintainer, the risk is continuity and security patching rather than licensing, so pin the version and read the source once before it touches money.