- How do I install torann/currency in a Laravel application?
- Install it with composer require torann/currency. Laravel's package auto-discovery registers the service provider and the Currency facade, so no manual registration is usually needed. Publish the config file with the vendor:publish command, then set your base currency and exchange-rate driver in config/currency.php. After that you can call the facade anywhere in your application.
- Which exchange rate providers does torann/currency support?
- Conversion is delegated to pluggable exchange-rate drivers, and the shipped drivers are declared in the published config file. Before adopting the package, check that one of those drivers matches a provider you already have a contract, API key, and security review for. If none does, factor in a new vendor, a new credential store entry, and a new line item as part of the evaluation. Swapping drivers is a config change, but onboarding a provider is a commercial and security decision, not just a code one.
- How do I convert one currency to another using the Currency facade?
- You use the Currency facade to format, parse, and convert amounts, with the base currency defined in the config file. Conversion pulls a rate from the configured driver and applies it to the value you pass in. Keep conversions at the presentation edge, for indicative prices and admin-facing totals, rather than using them to determine amounts you persist. If conversion results need to be stored, snapshot both the rate and its timestamp alongside the value.
- Does torann/currency cache exchange rates, and can I change the cache TTL?
- The package supports caching of exchange rates, and caching settings live in the publishable config file. Tune the TTL deliberately: an over-aggressive cache serves stale prices on customer-facing pages, while no cache means latency and provider throttling. Because rates change continuously, choose a TTL that matches how fresh your pricing actually needs to be. Cache configuration is one of the first things to review in a production readiness check.
- Which Laravel versions does torann/currency support?
- The only release evidence available is a Laravel 13.x compatibility line, which is a maintenance signal rather than a full capability statement. Confirm in composer.json whether that constraint is additive, meaning it still supports Laravel 11 and 12, or whether it is 13-only. Check the implied PHP floor as well, since a raised minimum PHP version can be a harder infrastructure constraint than the package itself. Pin your constraint accordingly before rolling it out across an estate.
- Can I set fixed exchange rates for testing or replaying past transactions?
- Pluggable drivers mean you can supply a deterministic rate source instead of hitting a live provider during tests, which keeps your test suite fast and offline-safe. Confirm in the docs how to bind or configure a fixed driver and whether a forced-rate option exists. For replaying historical transactions, the reliable pattern is to persist the rate and timestamp with the transaction rather than re-deriving it later. That removes your dependence on any provider's historical endpoint.
- Does torann/currency handle per-currency decimals and locale-aware formatting?
- The package is built for currency formatting and parsing, and per-currency precision and symbol placement are typically driven from configuration. Verify whether those definitions come from a maintained locale data source or are hand-maintained, and confirm behaviour for zero-decimal currencies such as JPY and three-decimal currencies such as KWD. Also check whether formatting is genuinely locale-aware or English-centric for symbol placement and separators. Test the specific currencies in your market before trusting the output.
- Is torann/currency safe to use as the source of truth for stored monetary values?
- No. It is a presentation and conversion helper, not a ledger, and it should not become the authority for persisted amounts, invoices, refunds, or settlement. Legitimate uses are display formatting, indicative converted prices, and admin-facing totals. Storing floats for money is a correctness defect that surfaces in finance review rather than code review, so confirm what numeric type crosses your API boundary and whether rounding mode is configurable. If a team proposes the package as the system of record for money, treat that as a design escalation.
- Does torann/currency expose historical exchange rates for a past date?
- Whether historical rates are retrievable depends on the driver and the upstream provider's API, so verify this against the docs and your chosen provider before relying on it. Without historical rates you cannot reproduce an invoice, adjudicate a dispute, or pass an audit, which makes this a requirement to confirm early. The safer design is to store the applied rate and its timestamp on the record itself. That way past transactions remain reproducible regardless of the package or provider.
- Is torann/currency actively maintained, and what are the alternatives?
- Adoption evidence is thin, with effectively zero stars and zero dependents, so the maintainer is essentially the entire supply chain. Check the licence to confirm it permits an internal fork, review the release history and CI setup, and note the maintainer's time-to-compatibility after a Laravel major ships. If the risk is unacceptable, the in-house alternative is modest: formatting is small, and conversion is a provider integration plus a cache plus a snapshot table. Budget a few weeks to remove the dependency entirely if the package sits on a pricing-adjacent path.