Pricing Across Borders Is More Than Swapping Currency Symbols: Multi-Currency for Vibe Projects

We previously published a pricing & paywall guide about pricing structure: how to split tiers, how to offer free trials, where to place the paywall. This article is pricing's next stop: what happens across the border — when users in Germany, India, and Brazil open your pricing page, what currency should they see? Who sets the exchange rate? Who pays the tax? That article decides "what price"; this one decides "how the price sells worldwide". We also have a solo-team tax-compliance guide about your personal tax filing; this article covers only the product side — tax collection and invoicing at the moment of checkout.

The hidden tax of USD pricing: non-US users pay 3–5% more

Almost every vibe-coded project starts pricing the same way: $19/month, one price worldwide. Looks fair, right? But for a German user, what actually happens is: Stripe charges in USD, then their bank converts to euros at the card-network rate plus a 1–3% currency-conversion fee. They don't pay $19 — they pay €17.60 plus a fee nobody can explain. Meanwhile your competitor (with localized pricing) lists €19 all-in.

That "hidden tax" has three consequences:

• Conversion leakage: the pricing page says $19, checkout says €17.83 (with conversion) — the user feels "the price went up" and abandons.
• Support tickets: "why was I charged differently than listed?" — explained one by one, forever.
• Refund disputes: the user does the math in euros, feels overcharged, opens a Stripe dispute — your chargeback rate climbs.

The conclusion: think about currency on day one of going global, not "when we have overseas users". Because once the currency strategy is set, the price table, checkout, invoices, and refunds all follow it — changing late costs 10x changing early.

Three currency strategies: no best, only best-fit

Figure 2: The three strategies. The usual evolution: single USD → auto conversion → localized pricing — each step an upgrade once the previous stage has volume.

• Single USD pricing: $19 everywhere, Stripe auto-converts. Zero engineering; fits the just-started stage with <10% overseas users. Users eat the conversion fee.
• Automatic FX conversion: $19 × live rate = €17.42, rounded to €17. Looks localized, but the price floats daily — €17 today, €17.50 tomorrow. Weak trust. Fits the transition period.
• Localized pricing: $19 in the US, €19 in Europe, INR 499 in India — human-set prices. Highest conversion (stable prices, local psychological price points); the cost is maintaining a price table + anti-arbitrage. Fits "after you have volume".

One opinion: currency strategy evolves with your overseas-revenue share; it's not day-one architecture. Under 10% overseas: single USD. 10–30%: auto conversion. Over 30%: localized pricing. Localizing early is paying tax for users who haven't arrived.

Implementation: the price-display pipeline

Figure 1: The price-display pipeline. The iron rule: charge in whatever currency you display — showing euros and charging dollars makes the user pay an invisible conversion fee.

Unpacking the pipeline — every step has a trap:

1. Detect region: IP (server-side geo) is most common, but VPN users get misclassified; browser language is a secondary signal; the account's registered country is most accurate — the user chose it. Priority: account country > IP > browser language. Give users a manual "switch region" escape hatch for misdetection.
2. Look up the price table: localized price wins when present; FX conversion is the fallback. The table lives in your database, keyed by product × region.
3. FX conversion: fetch rates once daily (ECB / Fed public feeds) and cache for 24 hours — the price at checkout must be stable; it can't move in the 30 seconds the user types their card number.
4. Localized formatting: Intl.NumberFormat is the standard answer. Germany writes €19,99 (comma decimals); Japan writes ￥2,000 (no decimals). Never hand-assemble currency symbols — a formatting error hurts trust more than no localization.
5. Settle in the displayed currency: create one Stripe Price per currency and pass the matching priceId at checkout. Display euros, charge euros — the iron rule.

// Multi-currency price resolution: localized price first, FX fallback (Next.js server)
import { cache } from "react";

const FX_TTL = 24 * 3600; // cache FX rates 24h — checkout prices must be stable

// Price table: product × region → local price (human-set; falls back to conversion)
const LOCAL_PRICES: Record<string, { amount: number; currency: string }> = {
  "pro:US": { amount: 1900, currency: "USD" },
  "pro:EU": { amount: 1900, currency: "EUR" }, // Europe €19 — not converted from $19
  "pro:IN": { amount: 49900, currency: "INR" }, // India INR 499 — PPP pricing
};

export const getPrice = cache(async (product: string, region: string) => {
  const local = LOCAL_PRICES[`${product}:${region}`];
  if (local) return local;
  // No local price: USD baseline × cached FX rate, rounded to a friendly number
  const rate = await getCachedFxRate("USD", regionCurrency(region));
  const converted = Math.round((1900 * rate) / 100) * 100;
  return { amount: converted, currency: regionCurrency(region) };
});

export function formatPrice(amount: number, currency: string, locale: string) {
  // Never hand-assemble symbols! Intl handles commas/decimals/symbol placement
  return new Intl.NumberFormat(locale, {
    style: "currency",
    currency,
  }).format(amount / 100);
}
// formatPrice(1999, "EUR", "de-DE") → "19,99 €"
// formatPrice(1999, "EUR", "fr-FR") → "19,99 €" (symbol placement differs — don't hand-roll)

On the Stripe side: create one Price per currency (price_usd_19, price_eur_19, price_inr_499) and pass the region-matching priceId in the Checkout Session. A Price's amount is immutable once created (archive and recreate to change) — so remember to update the mapping in your price table on repricing. The most common ops omission.

Localized pricing: PPP discounts and anti-arbitrage

Localized pricing is built on PPP (purchasing-power parity): an Indian user's income is ~1/20 of a US user's, so $19 feels like $380 to them. Not discounting is abandoning the market. The practice:

• Tier it: US/EU/JP/AU = baseline; LatAm/SEA = 60–70%; India/Africa = 30–50%. Three tiers is enough — don't overcomplicate.
• Example table: pro tier at $19 US / €19 Europe / R$49 Brazil / INR 499 India. Note Europe's €19 is not $19 converted (~€17.50) — it's the local psychological price point. The number 19 sells as well in Europe as in the US.
• Anti-arbitrage: at INR 499 (~$6), a US user with a VPN gets 70% off. The three-piece toolkit: ① verify billing country matches IP country at payment; ② lock account region (changeable once per 90 days); ③ for deeply-discounted tiers, require local payment methods (UPI/PIX). Arbitrage defense targets scale, not individuals — one user VPN-ing to save $13, let them; someone bulk-reselling accounts, that's when you act.

The opinion: PPP pricing isn't "selling cheap" — it's "selling at local willingness-to-pay". INR 499 feels in India the way $19 feels in the US, and conversion is higher for it. Global uniform pricing looks fair but is really price discrimination against lower-income regions — discriminating by excluding them.

Tax: selling abroad means paying tax abroad

Figure 3: The three compliance tiers. One sentence: pay tax where you collect money. Stripe Tax is the answer for 90% of solo projects; consider MoR past $10k/month.

The most-ignored block in vibe coding: you collected €19 in Germany, which includes 19% VAT — owed to Germany. Skip it? EU VAT applies by place of supply; get caught and it's fines. Three tiers:

• Tier 1: Stripe Tax — auto-calculates rates by customer address at checkout and generates tax reports. Costs ~0.5% extra to Stripe; enough for 90% of solo projects. Enabling it is one config line: automatic_tax: { enabled: true } on the Checkout Session.
• Tier 2: manual rate tables — EU flat 20% VAT, most US states exempt digital goods, ignore the rest. Crude; fits "EU+US only". But you track rate changes yourself — for teams with accountants, not solo founders.
• Tier 3: Merchant of Record (MoR) — Paddle / Lemon Squeezy act as the legal seller: they collect tax, issue invoices, and file returns; you just get paid. Costs 5%+. Fits $10k+/month across dozens of countries.

Invoicing is tax's other half: EU B2B customers need invoices to reclaim VAT — with your tax ID, their tax ID, rate, and tax amount. Stripe Tax / MoR generate compliant invoices automatically. Self-built templates must be reviewed by an accountant — a malformed invoice means the customer's finance team rejects it, and the money doesn't come.

Boundary restated: this article is the product side (collecting tax and issuing invoices at checkout); your personal income-tax filing as an indie developer is a different beast — see the site's solo-team tax-compliance guide.

Refunds and FX: refund in the original currency

Multi-currency's last trap is refunds: a user paid €19, refunds a month later — do you return €19 or convert at today's rate? Answer: refund the original currency and amount (Stripe refunds work this way by default).

• Don't "convert to USD at today's rate" — FX drift makes the user feel shortchanged. Dispute incoming.
• Who eats the FX loss on refunds? Stripe's rule: no fee on the refund itself, but the original conversion spread isn't returned. Eat those cents yourself — arguing over pocket change costs you the review.
• Partial/pro-rated refunds: same rule, original currency, no conversion.

Price psychology: localize the charm pricing too

The "9" in $19.99 signals "cheap" in the US — but the psychology isn't universal:

• Japan: ￥1,980 outsells ￥2,000, but ￥1,999 feels "calculating" — Japanese shoppers respond differently to 9-endings; round to 980/1980 feels more natural.
• China: 8 is the lucky number; ￥88/￥188 convert almost superstitiously better than ￥89/￥189. Worth doing if you sell into China.
• Europe: €19 beats €19.99 — Europeans tolerate round prices better; they read as more "honest".
• Rounding rule: auto-converted prices (€17.42) must be rounded — to a psychological price (€17 or €19), never the exact conversion. A to-the-cent converted price looks "machine-made" and trust drops a notch.

The opinion: localized pricing sets "psychological price points", not "FX conversions". €19 and $19 share digits but different logic — "€19 feels right in Europe" vs "$19 feels right in the US". FX is a reference; psychology is the answer.

Payment methods: beyond currency, local rails matter more

Multi-currency with credit-cards-only? In many markets that's the same as nothing:

• Latin America: Brazil's PIX (instant transfer), Mexico's OXXO (cash at convenience stores) — low card penetration; without local rails, conversion gets cut in half.
• India: UPI dominates absolutely; cards cover only tier-1-city white collars. INR 499 pricing plus UPI is the complete India strategy.
• Southeast Asia: GrabPay, GCash, Dana — different per country.
• Europe: SEPA direct debit, iDEAL (Netherlands), Sofort (Germany) — cards aren't even the default.

Stripe supports most of these natively — a few payment_method_types entries. But note: each rail has different fees, settlement times, and refund rules — glance at the fee table before enabling. The opinion: currency solves "understandable"; payment methods solve "payable" — the former is UX, the latter is life-or-death.

Free trials + multi-currency: which currency bills at trial end

A classic trial trap: a user starts a 14-day trial at INR 499 in India — what gets charged at expiry?

• Lock the trial-start currency and price: trial started showing INR 499, expiry charges INR 499. Expectations clear, zero disputes.
• Never reprice mid-trial: you raise India to INR 599 on trial day 10, expiry charges 599 — the user feels phished. Repricing applies to new users only; existing users (trials included) keep their start price.
• State the currency in the expiry reminder: "your card will be charged INR 499 in 3 days" — not "$6.01". The reminder's currency must match what was originally displayed.

This is downstream of the paywall article's "trial design": that one decides "whether and how long to trial"; this one decides "how trials settle across currencies". Together they're the complete trial strategy.

Analytics: read revenue by currency — don't let FX fool you

Once multi-currency ships, your MRR becomes an FX-illusion minefield:

• One reporting currency: pick USD (or your home currency); convert every receipt at the settlement-day rate. Never restate history at "current rates" — last month's €1000 was $1080 then; history doesn't change because it's $1050 now.
• Split growth by currency: add a per-currency column next to total MRR on the dashboard. "Total MRR +5%" might be "USD +10%, EUR −5% netting out" — currency-mix shifts are signal (e.g., a market taking off).
• FX-volatility reserve: once euro revenue passes 30%, hold a 3–5% volatility reserve. Not forex speculation — just avoiding the shock of "euro down 5%" becoming "this month was for nothing".

A true story: 30 days after a pricing-page revamp

Fictional-but-typical: indie dev Nan's SaaS — 70% US, 20% Europe, 10% rest. Pricing page in USD only. One day he ships three things: ① euro prices for Europe (€19, tax-inclusive clearly stated); ② Stripe Tax on; ③ SEPA added for Germany.

30 days later: European conversion 1.1% → 1.7% (+55%), "pricing question" tickets 8/week → 1/week, European refund rate 4.2% → 2.8%. Total work: one weekend. Nan's takeaway: "I thought multi-currency was 'big-company stuff'. Now I think it's 'have-European-users stuff' — the barrier wasn't technical; it was me assuming the barrier was high."

The lesson: multi-currency ROI on a product that already has overseas users is immediate — because it fixes leakage, not increment: people who were going to pay but got talked out of it by the currency experience.

The currency switcher's UX details

The little currency switcher (USD ▾) on the pricing page is small, but details decide trust:

• Default to the visitor's currency, not USD. A German visitor seeing $19 and having to switch manually — lost at step one.
• Remember the choice: persist in localStorage; next visit uses it. A user who switched to euros wants euros — don't reset.
• State tax-inclusive/exclusive on switch: Europe expects tax-inclusive prices, the US expects exclusive. Switch the tax language with the currency — €19 (incl. VAT) vs $19 (+tax) are two scripts; hardcoding one scares off the other half.
• Checkout must not change it: pricing page said euros, checkout must say euros. Mismatched totals are the fastest trust-killer — "the price changed" is a danger signal in every culture.

B2B vs B2C: two different currency logics

Everything above is B2C. Selling team/enterprise plans? Different logic:

• B2B locks to the customer's billing country, not IP: a German-registered company with traveling employees — IPs change daily. Currency locks to the registered country, in the contract.
• Enterprise wants quotes: $19 × 50 seats × 12 months = $11,400 — finance needs approvals. Quotes lock price and currency for 30 days; FX moves don't matter inside the window. Build a quoting flow or use Stripe Quotes.
• Invoices are mandatory, not a perk: B2C users don't care; B2B customers don't pay without compliant invoices. B2B invoices need: tax IDs, company header, line items, payment terms (Net 30).
• Lock FX on annual plans: €228/year, charged once, locked 12 months. Never "bill monthly at that month's rate" — corporate finance hates uncertainty most.

One sentence: B2C currency is a UX problem; B2B currency is a process problem. The former competes on local feel, the latter on financial compliance. If your product does both, you need both logics.

Launch checklist

• Currency strategy chosen: single USD / auto conversion / localized pricing (evolving with overseas-revenue share)
• Region detection on three signals: account country > IP > browser language + manual switch
• Price table on product × region; localized price first, conversion fallback
• FX rates cached 24h; checkout prices stable
• Intl.NumberFormat for display; never hand-assembled symbols
• Display currency = charge currency (matching Stripe multi-currency Prices)
• PPP tiered pricing + anti-arbitrage trio (billing-country check / region lock / local rails)
• Stripe Tax on (automatic_tax.enabled); invoices auto-generated
• Past $10k/month across many countries → evaluate MoR (Paddle/Lemon Squeezy)
• Refunds in original currency and amount, no conversion

One honest closing note: multi-currency is never technically hard — what's hard is awareness. AI won't proactively warn you "German users owe VAT"; it'll just translate $19 into €19 and leave it there. Yet an expat product's life or death hides exactly in those "just translate it" corners. Once pricing crosses borders, you compete not on price but on local feel: local currency, local formats, tax-inclusive prices, compliant invoices — every detail telling the user "this was made for your market".

And the ultimate test of local feel is simple: find a friend in your target market, open your pricing page and checkout, say nothing, and watch for frowns. Every frown marks an unchecked box on this article's checklist.