A customer in Berlin opens Increddy, sees prices in euros, adds a game key to their cart, and gets to checkout only to find their card is about to be charged in US dollars at whatever rate their bank applies that day. That's the exact failure case we designed around, and it comes from a single, very common conflation: treating "what currency do you see prices in" and "what currency will your card be charged in" as the same decision.
Why these are actually two different questions
Display currency is a UX preference. A shopper wants to understand what something costs without doing mental currency conversion, full stop. Charge currency is a payment and accounting decision: which currency actually settles, how fraud scoring treats the transaction, how the books reconcile at the end of the month. Nothing about wanting clear prices implies the underlying charge has to settle in that same currency, and nothing about wanting one settlement currency implies prices have to display in it either.
What the shipped design actually does
Increddy's cart follows the display currency the customer picks: switching currency re-prices the cart's contents in the new currency while preserving what's in it, and re-applies any coupon and the platform service fee after the switch. At checkout, card payments default to USD, stated explicitly before payment so there's never an ambiguous charge. A "pay in your currency instead" option unlocks local payment methods (Bancontact, EPS, Przelewy24, and similar, depending on the currency) for customers who'd rather avoid a foreign-currency card charge. If a USD card charge is declined, the checkout proactively suggests trying the local-currency path instead of just failing silently.
| Kryeo | Conflated model (one currency variable) | |
|---|---|---|
| Browsing prices | Separate variable: any supported display currency | Tied to whatever the charge currency ends up being |
| Card charge | Defaults to one currency (USD) for fraud/accounting simplicity | Varies by customer, multiplying fraud and reconciliation complexity |
| Local payment methods | Explicit opt-in, unlocks native-currency charging | Usually unavailable or inconsistently wired |
| Declined USD charge | Proactively suggests the local-currency path | Fails with no alternative offered |
The quieter bug this prevents
Medusa's core cart-update API resets currency to the store default on any cart mutation, a core-framework behaviour that would silently break the "cart follows your currency" feature if it went unnoticed. The fix was to avoid that endpoint for anything except carefully guarded updates, and to set currency-sensitive data (like UTM attribution) at cart creation rather than through a later update call. Catching a quirk like this before launch, rather than after a support ticket about "my cart changed currency on its own," is exactly the kind of thing that only surfaces from reading the actual framework behaviour, not its documentation.
Shipping checkout for an international audience?
If your checkout conflates what a customer sees with what their card gets charged, that's usually fixable without a redesign. We'll walk through your specific payment methods and tell you what changes.
Talk it through →The rule
Model display currency and charge currency as two independent variables from the start, not one setting that happens to drive two different UI surfaces. Default card charges to a single currency for your own accounting and fraud sanity, but say so explicitly before payment, and give customers who'd rather not take a foreign-currency card charge a real alternative. For the broader migration this checkout sat inside, see how we replaced Shopify's backend without touching the frontend. We design checkout flows like this under headless commerce engagements.