Currency Laravel Package

Technical Evaluation

Architecture fit. torann/currency is framework-native Laravel: a service provider, a facade, a publishable config file, and conversion delegated to pluggable exchange-rate drivers. For a Laravel estate that is the right shape — no sidecar, no second runtime, no bespoke bootstrapping, and an integration surface every Laravel engineer already recognises. The architectural question a TPM should force is not "does it install" but "which layer owns money in our system." This package is a presentation and conversion helper, not a ledger. Its legitimate home is the edge: display formatting, indicative converted prices, admin-facing totals. It must not become the authority for persisted amounts, invoices, refunds, or settlement. If a team proposes it as the source of truth for stored monetary values, that is a design escalation, not a package evaluation, and should be escalated as such before any code is written.

Integration feasibility. Mechanically low — composer require, publish the config, set a base currency and a rate driver, exercise the facade. The real feasibility work sits in three places, and each is a TPM-owned decision rather than an engineering detail. First, the rate provider: conversion is only as good as its upstream, so whether the shipped drivers match a provider we already contract with, or force a new vendor, a new API key, a new security review, and a new line item, is a commercial question to surface early. Second, precision semantics: whether amounts cross the API as floats or strings, and whether rounding mode and per-currency decimal places (JPY at zero, KWD at three) are configurable. Floats in money are a correctness defect that surfaces in finance review, not code review. Third, historiography: whether the rate that applied on a past date can be retrieved. Without it we cannot reproduce an invoice, adjudicate a dispute, or pass audit.

Technical risk. The only release evidence in this record is a single line — "Laravel 13.x Compatibility" — which is a maintenance signal, not a capability assessment. Adoption evidence is thinner still: effectively zero stars and zero dependents. There is no community backstop; the maintainer is the entire supply chain. Ranked: (1) upstream rate dependency — provider outage, rate limit, pricing change, or terms change silently degrades a customer-facing feature; (2) rate freshness versus caching — an over-aggressive cache shows stale prices, a missing one produces latency and throttling; (3) numeric correctness — rounding drift that compounds across line items and totals; (4) maintainer bus factor — a single-maintainer package on a pricing-adjacent path needs a credible fork plan and a licence that permits one; (5) framework coupling — confirm whether the 13.x bump is additive (11/12/13) or 13-only, and what PHP floor it implies, since that floor may be a harder infrastructure constraint than the package itself.

Key questions. Which exchange-rate providers ship out of the box, and does any match a vendor we already have a contract and security review with? Is caching present, configurable, and what is the default TTL? Does it expose historical rates, and can we inject a fixed rate for tests and for replaying past transactions? What numeric type crosses the API boundary, and is rounding mode configurable? Are per-currency decimals and symbol placement derived from a locale data source or hand-maintained config — and is formatting genuinely locale-aware or English-centric? What is the licence, and does it permit an internal fork? Is there a CI matrix and a security disclosure channel? What is the maintainer's historical time-to-compatibility after a Laravel major ships? And the question that frames all the others: what would building this in-house cost? Formatting is small; conversion is a provider integration plus a cache plus a snapshot table — plausibly a few weeks that removes the dependency entirely.

Integration Approach

Stack fit. Clean if the estate is Laravel and PHP at the version the 13.x alignment implies, and close to zero if it is not. This is a framework-tier dependency, not an org-wide standard: any non-Laravel PHP service — a queue worker in another framework, a Go settlement service, a Python reporting job — needs its own formatting and conversion answer, and that is exactly how money-handling divergence creeps in. Decide up front whether this package is the sanctioned formatter for the Laravel tier only, and record that scoping decision so a second source of truth for money formatting does not appear six months later via a payments vendor that bundles the same capability.

Migration path. Greenfield is trivial: install, publish config, set the base currency, wrap the facade in one internal service class, and call only that service. Brownfield is where the sequencing matters. The temptation is to retrofit formatting onto existing price-rendering call sites one by one, which spreads the facade across the codebase and makes the dependency expensive to remove later. Resist it. Instead, stand up the internal MoneyFormatter (or equivalent) wrapper first, migrate call sites to the wrapper rather than to the package, and keep the package behind that seam. For stored amounts, the migration path is separate and larger: if the schema does not already carry an explicit currency alongside every amount, that is the work item with a real deadline, because retrofitting an implicit base currency after data volume accumulates is expensive in a way the package adoption is not.

Compatibility. Confirm and write down four things before committing: the supported Laravel major range (is 13.x additive or a hard floor?); the PHP floor that implies, checked against every runtime we actually deploy on; the exchange-rate driver's own HTTP client and TLS expectations, since an outdated client in a locked-down egress environment fails at runtime rather than at install; and how the package behaves when the rate provider is unreachable. That last one is a compatibility question with the customer, not with the framework — decide whether the fallback is last-known rate, base currency, or a hidden price.

Sequencing. Do it in this order, and do not skip ahead. (1) Lock base-currency standardization and the stored-amount currency field while data volume is still small. (2) Choose the rate provider and write the freshness policy — whose rates, what cache TTL, what happens when they are down — as a product decision, not a config default inherited from the package. (3) Pick one low-traffic, display-only surface as the pilot: a marketing price display, an internal admin total, or a "shown in your currency for reference" label. (4) Instrument conversion display and conversion billing as separate events so a later conversion-lift experiment is not misread. (5) Only then evaluate expanding coverage. Keep it off the critical path of checkout until a proper review clears it.

Operational Impact

Maintenance. The package is small and boring, which is the right profile for a display concern — but small and boring here also means thin. Zero dependents and single-line release notes mean no community backstop, no downstream bug reports to borrow, and no one else's production traffic hardening the code path before ours does. The practical posture: pin the version exactly, wrap the facade behind one internal service so removal is a one-file change, and budget a small recurring line item for "verify this still works and is still maintained" each time a Laravel major ships. Confirm the licence permits an internal fork before adopting, because a single-maintainer package on a pricing-adjacent path needs a fork plan that is legal as well as technical.

Support. Support burden splits into two halves with very different owners. The formatting half is genuinely low-touch — symbols, decimals, and separators are configuration, so market-specific presentation changes without a code deploy, which is a real operational win for a pricing or marketing team iterating on market coverage. The conversion half is not low-touch: it inherits every SLA, term change, rate limit, and outage of the upstream provider. Name an internal owner for the provider relationship and the freshness policy, and make sure that owner knows a visibly stale converted price generates support tickets and, in some markets, compliance questions. Document the display-versus-charge rounding rule explicitly — if the displayed price is not guaranteed to match the charged price, state the tolerance up front rather than discovering it in a customer complaint.

Scaling. Scaling characteristics are dominated by the rate fetch, not by the formatting math. Formatting is CPU-trivial. Conversion at volume is a caching problem: without a cache in front of the provider, every rendered page becomes an outbound API call, which produces latency under load and throttling at the worst possible moment (a campaign, a price change, a traffic spike). Verify the cache is actually supported, that its TTL is configurable, and that the chosen TTL matches the freshness policy rather than a default inherited from a config file. The other scaling dimension is organisational: every additional service that needs currency display and cannot use this package is a second implementation to keep consistent, so the scaling question for a TPM is coverage — how far does the Laravel-tier standard actually reach, and what governs the services outside it.

Failure modes. Enumerate them and decide the response before launch. Rate provider down or rate-limited: what does the customer see — last-known rate, base currency, or nothing? Stale cache: how stale is too stale, and is there an alert at that threshold? Rounding drift: where does conversion round, and does it compound across line items and totals in a way finance will find? Numeric representation: if amounts are floats anywhere in the path, treat that as a latent defect rather than a risk. Maintainer abandonment: what is the trigger for executing the fork, and who owns it? Framework upgrade: when the next Laravel major lands, how long can we run on the current major before the package catches up, and does that window fit our upgrade cadence? Historical rate absence: without the rate that applied on a given date, an invoice dispute cannot be adjudicated — this is a product failure mode, not just an engineering one.

Ramp-up. Engineer ramp-up is near-zero for anyone with Laravel experience: service provider, facade, config, done — which is precisely why the guardrails have to be deliberate, because it is easy and cheap to spread this dependency across the codebase before anyone has decided the boundary. The real ramp-up cost is elsewhere. Product and finance need to agree the base currency, the per-market rounding rule, the display-versus-charge tolerance, and the freshness policy — decisions the package deliberately leaves open and which no amount of engineering effort will make on their behalf. Estimate the total honestly: the TPM's cost here is a handful of cross-functional decisions plus a wrapper class, not an integration project. The package makes the multi-currency display hypothesis cheap enough to test as a scoped experiment; the decisions are what make the experiment interpretable.

Caveat to state plainly to stakeholders: the available documentation describes what the package can do, not evidence of how well it does it — no meaningful adoption base and no support-matrix evidence in this record. That is enough to justify a scoped pilot on a low-stakes display concern in one service. It is not enough to put this on a revenue-critical path, and its presence must not be read as evidence that multi-currency billing is solved.