Local currency pricing on a landing page: should you display it?

A coach based in North America lands on your landing page. The price shown: "€89". They vaguely know the euro is worth a bit more than the dollar, but not exactly how much — so they open a new tab, type "89 euros in dollars" into a search engine, get a number, and come back… or don't. That detour, even fifteen seconds long, is a friction point most French-speaking landing pages completely ignore the moment they also target an English-speaking or North American audience. The question isn't just "should I translate my page", it's also: which currency should the numbers be in?

Why the displayed currency changes the decision, not just the reading comfort

This isn't just an aesthetic question. Back in 1985, economist Richard Thaler showed, in his foundational paper on "mental accounting", that a buyer evaluates a price against a mental reference point rather than in absolute terms (Thaler, 1985). A foreign currency doesn't offer that immediate reference point: the brain has to convert first, then compare — two steps where a price in local currency only needs one. More specifically for cross-border online shopping, a 2021 study by Xi Chen and Hag-Min Kim published in International Trade, Politics and Development shows that the "psychic distance" a buyer perceives — of which displayed currency is a concrete component — directly affects their trust and purchase intent (Chen & Kim, 2021). A price in an unfamiliar currency isn't neutral: it's a quiet but real signal that the page wasn't built with this visitor in mind.

The problem specific to a statically generated landing page

If your landing page is statically generated with generateStaticParams — the recommended choice for speed and SEO, see our guide on deploying Next.js on Vercel — the HTML shipped to the browser is the same for everyone: it was frozen at build time, long before any visitor shows up. At that moment, nothing tells you whether the page will end up in front of a reader in Lyon or in Toronto. Adapting the display to the visitor's currency can't happen at build time — it has to happen afterward, once the page has actually reached the visitor's browser.

Detecting a visitor's likely currency without a cookie banner

Good news: guessing a visitor's likely currency requires no personal data, so no consent banner — the same principle covered in our article on cookieless analytics. Three signals, from simplest to most reliable:

• The browser's timezone, via Intl.DateTimeFormat().resolvedOptions().timeZone — a client-side clue available with no extra network call.
• The Accept-Language header sent with every HTTP request — a good clue about language, a bit less direct about country.
• IP geolocation provided by the hosting platform (on Vercel, the x-vercel-ip-country header set by the edge network) — the most direct signal for inferring a country, and from it a likely currency.

None of these three signals identifies a person: they're request metadata, not personal data under GDPR, so no consent banner is needed for this use alone — see our guide on GDPR-compliant landing page forms for the line you shouldn't cross if you later combine them with marketing tracking.

Converting the price: a rounded fixed rate beats a real-time API

Two approaches compete here. The first queries a currency-conversion API on every render: precise, but fragile — one more network call that can delay or flicker the displayed price, which hurts the page's Core Web Vitals, for a decimal-perfect figure that gives a false sense of precision on an amount that won't be the exact one charged anyway. The second sets rounded prices per major currency zone — €89 becomes $99, not $96.43 — updated by hand every few months. For a one-time purchase under €250, the gap versus today's exact rate is negligible next to the gain in simplicity and reliability; it's the approach most sellers of fixed-price digital products settle on.

The displayed price isn't always the charged price — the caveat you can't skip

One thing to watch: if your payment provider — say, a Stripe Payment Link configured in euros — only charges in a single currency, the localized price you display is never the actual amount charged; it's an indicative conversion. Say so clearly, with wording like "about $99" rather than a firm price, and note that the visitor's card will apply their bank's rate on the day, not the one shown on the page. Skipping this nuance isn't just an honesty issue: a price shown as firm and then charged differently at checkout fuels refund requests and distrust — the opposite of the intended effect, and the same mechanism behind the dark patterns covered in our dedicated article.

Full multi-currency checkout or a simple indicative conversion: which to pick

A true multi-currency setup — several Stripe Payment Links, one per currency, or Stripe Adaptive Pricing automatically adjusting the amount at checkout — makes sense for a SaaS with recurring customers across several regions, where the implementation cost pays for itself over a customer's lifetime value. For a fixed-price, one-time purchase — an ebook, a course, a template like LanderKit's — the effort is rarely worth it: a reference price in one currency, paired with an indicative conversion for others, is enough to remove the main friction point without complicating accounting or customer support.

What this changes on your page starting today

Before investing in full multi-currency support, start with the cheapest move available: show, under the main price, an indicative conversion in the visitor's likely currency, computed client-side with Intl.NumberFormat and a rounded rate you update by hand. LanderKit's ten templates (€89 each, €229 for the full pack) ship as standalone Next.js code: each template's price block — see for example SaaS Waitlist (demo) — is an isolated component, easy to wire up to a currency-detection check without touching the rest of the page.