multi-currency-pricinglisted

# Multi-currency pricing Two different things get called "multi-currency pricing," and conflating them causes real bugs (charging the wrong amount, promising a rate you can't honor): 1. **Display-only conversion** — canonical price stays in one base currency (e.g. USD); the page shows a localized *estimate* in the visitor's currency; the charge still happens in base currency. This is what most SaaS pricing pages and many checkout flows do. 2. **True multi-currency pricing** — the customer is actually charged in their local currency, at a rate set by your payment provider (Stripe, Adyen, etc.) at transaction time. **This skill covers #1 — the display layer.** The charge rate always comes from the payment provider, never from an FX API you called for display. Never present the rate this skill computes as the transaction rate; label it an estimate and let the payment provider quote the real one at checkout. If the task is actually "charge in local currency," that's a payment-provider integration question, not an FX-API question — say so and stop building an FX-driven price engine for it. ## 1. Server-side rate fetch + cache — never call the FX API per page view A pricing page rendered for every visitor must not trigger an API call per visitor. Fetch on a schedule, cache app-side, serve from cache. For a short price list, batch-convert in one call instead of one call per currency: ```bash curl -X POST "https://api.exchangerate.dev/v1/convert" \ -H "Content-Type: applicat