Currency Rate Laravel Package

Getting Started

Install the library with Composer and verify it actually resolves against your PHP version before writing any code:

composer require redcode/currency-rate

Be aware up front that the last tagged release is from September 2015 and the package has essentially no downstream usage. The first thing to do is open vendor/redcode/currency-rate/src and read the source directly — the public footprint is small, and there is no meaningful documentation beyond the README. You are looking for the loader/parser classes and the provider classes that fetch rates from external services.

Your first use case will almost always be the same: convert a stored amount from one currency to another using today's rate. A minimal flow looks like:

1. Instantiate the rate loader for the provider you want (European Central Bank / a Yahoo-style feed / etc.).
2. Fetch the rate collection.
3. Look up the pair you need and multiply.

$loader = new \RedCode\CurrencyRate\Loader\...;   // whichever loader the package ships
$rates  = $loader->load();                        // returns a collection of rates
$rate   = $rates->getRate('EUR', 'USD');

$converted = $amount * $rate;

Because the library is a plain PHP package (not a Laravel package), there is no service provider, no facade, and no config file. You wire it in yourself. Treat it as a low-level building block, not framework glue.

Implementation Patterns

Wrap it, don't sprinkle it. The library has no Laravel integration, so create a single application service that owns it:

class ExchangeRateService
{
    public function __construct(private RateRepository $repo) {}

    public function rate(string $from, string $to): float
    {
        // read from your DB cache first, fall back to the package
    }
}

Bind this in a service provider and inject it where needed. This isolates you from the package's API and makes it trivial to swap it out later (which you probably will).

Cache aggressively in your own storage. The package does not give you Laravel caching, DB persistence, or a scheduler. Exchange rates change at most a few times per day, and provider endpoints are rate-limited. The standard pattern:

• A scheduled command (php artisan rates:refresh) runs on a cron / schedule().
• It calls the package, normalizes the output, and upserts rows into a currency_rates table (base, quote, rate, fetched_at).
• The whole app reads from that table. Nothing hits the provider at request time.

Store a base currency and derive pairs when you need cross-rates (USD→PLN via EUR), because most free feeds are anchored to a single base (commonly EUR or USD). Doing the triangulation yourself avoids depending on which pairs the provider happens to publish.

Use it in a fallback chain across providers. The package's value is that it exposes a common shape over multiple feeds. Register one primary provider and one backup, and call them in order in your refresh command. This is the one genuine benefit the library offers — you get a uniform loader interface for feeds you would otherwise parse by hand.

Guard conversions at the boundary. Any place you display money, resolve the rate once per request (or read it from a cached array), and convert at the edge. Do not convert back and forth — rounding will drift.

Gotchas and Tips

• It is effectively abandoned. Last commit/release 2015, 4 stars, 0 dependents. There will be no security patches. Run composer audit and expect it to be flagged eventually. Plan an exit.
• PHP version compatibility is the first wall. A 2015 package predates PHP 7 type declarations and PHP 8. If it fails to install on PHP 8+, you will need composer require --ignore-platform-reqs (risky) or fork it. Check for mcrypt, old curl usage, or each()-style calls that were removed from modern PHP.
• Provider endpoints have almost certainly moved or died. Free rate APIs (Yahoo, Google Finance scrapers) from that era are gone. Expect to either patch the provider class or write your own loader that satisfies the package's loader interface. The loader interface is the reusable part; the shipped providers likely are not.
• No caching, retries, or timeouts built in. Wrap every call in try/catch, add a timeout on the HTTP client, and never call a provider synchronously inside a web request. One hung upstream connection will tie up a PHP-FPM worker.
• No rate limits or API keys handled. Most modern free providers require a key; the package's 2015 providers were written when they didn't. You will be adding auth and throttling yourself.
• Return types and precision. Rates come back as floats or strings depending on the parser. Cast to a decimal-safe type (string + BCMath, or integer minor units) before doing money math. Comparing floats for equality is a bug waiting to happen.
• Testing tip: the loaders are the seam to mock. In tests, bind a fake loader that returns a fixed set of rates — do not let unit tests hit the network, and never let CI hit a dead 2015 endpoint.
• Extension point: if you decide to keep it, implement your own loader against the package's interface (e.g. LoaderInterface) pointing at a maintained source like the ECB XML feed or exchangerate.host. That preserves the abstraction while removing the dead provider code.
• Honest recommendation: for a new project, this package is more liability than convenience. A 30-line wrapper around a current free API (ECB daily XML, exchangerate.host, openexchangerates, or moneyphp/money for the math side) gives you the same result with maintained code, tests, and modern PHP support. Use redcode/currency-rate only if you are inheriting it and need a stopgap — and isolate it behind your own service so removing it is a one-file change.