Currency Context Api Laravel Package

Product Decisions This Supports

• Multi-currency and localization roadmap sequencing. This package is the API-facing layer of a currency-context capability — it answers "which currency is this user, cart, or tenant operating in, and how is that presented over HTTP?" That is a prerequisite decision for any international pricing work: whether currency is a per-request concern, a per-account attribute, or a per-transaction fact. Adopting or rejecting it forces that conversation early, which is where most localization roadmaps actually fail.
• Build vs. buy for the presentation edge. A "presentation adapter" is deliberately thin: it maps domain currency context into an API contract. The PM decision here is not "buy a currency engine" but "do we want our API serialization of currency state to be a reusable, versioned module or hand-rolled per endpoint?" Hand-rolling is cheap once and expensive at the fifth endpoint, when three teams serialize rounding and formatting differently.
• Architecture posture: ports and adapters. The naming signals a hexagonal design where the domain module (module-currency-context) is decoupled from the transport. That supports a strategic bet: keep currency rules out of controllers so a future gRPC, GraphQL, or mobile-BFF surface reuses the same context. This is a decoupling decision, not a feature decision.
• Concrete feature use cases to validate against: storefront currency switcher, geo/IP-based presentment currency with a locked settlement currency at checkout, B2B tenant-level billing currency, price display with locale-aware formatting and rounding rules, and currency context propagation into reporting/analytics events.
• Risk budgeting for a low-signal dependency. Zero stars, zero dependents, and an unasserted license are themselves product inputs. This supports a "reference implementation, not a dependency" decision — useful for shaping your own adapter contract, not for putting on a critical path.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel/PHP and already intend to separate currency context from transport concerns.
• You have an internal or forkable copy strategy — you are prepared to vendor the code, own it, and treat upstream as a starting point rather than a maintained dependency.
• You need a contract reference: what fields a currency-context endpoint should expose, and how to keep that stable across clients.
• Your team already runs (or is standardizing on) the same module family, so the adapter slot is genuinely reusable rather than ornamental.
• Legal has cleared or can clear the NOASSERTION license — this is a hard gate, not a formality. Unspecified licensing blocks redistribution and often blocks enterprise procurement outright.

Look elsewhere when:

• You need FX rates, tax, or price calculation. This package presents currency context; it does not source rates or compute money. Pair it with a dedicated money library (moneyphp/money, brick/money) and a rates provider — those are mature and well-supported.
• You need a supported dependency with a community. Zero stars, zero dependents, and no visible release discipline mean no peer-validation and no upgrade safety net. For anything customer-facing and revenue-touching, that is disqualifying on its own.
• You need SLAs, security review artifacts, or a CVE response path. None of these are inferable from a package with no adoption.
• Your surface is a single endpoint or a monolith with one currency. The abstraction cost exceeds the benefit; inline the logic and revisit at the second currency.
• The last-release date (2026-10-26) reads as anomalous relative to your evaluation date — verify the repository and tag provenance before any procurement or security sign-off, since an implausible release timeline is a supply-chain due-diligence flag, not a detail.

How to Pitch It (Stakeholders)

To executives: This is a small, unproven open-source PHP component that standardizes how our API exposes currency information. It is not a payment or pricing engine, and it is not a vendor commitment. Its value is architectural: if we adopt the pattern it encodes, every product surface — web, mobile, partner API — reads currency the same way, which is the difference between a clean multi-currency launch and three teams shipping three rounding behaviors. Cost to evaluate is days, not quarters. Recommendation: fund a one-week, time-boxed spike to extract the contract and validate it against two real endpoints, with an explicit expectation that we own the resulting code. Do not place it on a revenue-critical path until it has survived that spike and cleared legal review of its license.

To engineering: Treat this as a reference implementation of a presentation adapter for currency context, not a dependency to pull and forget. Read it for the contract shape — context resolution, serialization, and where the domain boundary sits — then decide whether to vendor, fork, or reimplement against the same port. The upside is contract stability and reuse across API surfaces; the cost is that you inherit maintenance from a project with no external consumers. Budget for a thin internal wrapper and contract tests so an upstream abandonment is a non-event. Also flag the license status (NOASSERTION) before any code enters a distributed artifact.

To product and design: The capability enables per-market price presentation, tenant-level billing currency, and checkout-time currency locking without re-litigating formatting rules per feature. It does not change what we charge — it changes how consistently we say it.