"Multi-currency ready" appears on almost every e-commerce feature list, including ours. It is one of the least useful phrases in the category, because it describes three genuinely different capabilities that differ by an order of magnitude in cost.
When someone asks us for multi-currency, they want one of these:
- Show the price in my visitor's currency, charge in mine.
- Charge in the visitor's currency, settle into my account.
- Set different prices in different markets, independently.
The first is a display feature. The second is a payments and accounting project. The third is a commercial decision that happens to need software. Confusing them is why this line item produces surprise invoices, and why some stores end up with a currency switcher that creates more support tickets than sales.
Work out which one you are buying.
Level 1: display conversion
The visitor sees "≈ $42" next to a price that is really 520,000 UZS. You charge in your own currency. The card network handles the rest.
What it takes: an exchange-rate source, a refresh schedule, and a formatting layer that knows each currency's symbol position and decimal convention. Days, not weeks.
What it buys you: the removal of a real friction. A price in a currency someone cannot estimate is a price they have to do arithmetic on, and some of them will not.
Where it goes wrong, and this is the part that is usually skipped:
Say what is happening. If the charge will be in a different currency from the number shown, say so on the page — "charged in UZS" next to the converted figure. A customer who sees $42 and a $44.10 statement line has been surprised by their own bank's conversion, and they will blame you.
Never let a converted figure become a commitment. The moment a displayed conversion appears on an invoice, a confirmation email or a refund, you have accidentally entered Level 2 without building it.
Handle rounding deliberately. An automatic conversion produces $41.83. That is a number no merchant would ever choose. Decide whether you round for readability, and accept that rounding means the conversion is approximate — which is fine, as long as you have said it is.
Pick a rate policy and write it down. How often does it refresh, from where, and what happens if the source is unavailable? A stale rate is usually harmless; a rate that silently becomes zero is not.
When it is the right answer: you sell into one market, you are paid in one currency, and some of your visitors think in another. That is most businesses.
Level 2: charging in the buyer's currency
The customer is charged 42 USD, and that is the figure on their statement.
This is a different class of project, because now the currency is part of the transaction rather than part of the page.
What it takes:
A provider that supports the currency. Not all do, and not for all methods. This is the first constraint and it is frequently the binding one. On Knigopoisk — a store selling across several currency zones — the checkout offers only the providers that support the currency the customer has chosen, out of a set covering USD, EUR and RUB across cards, ruble methods and crypto. That is not a nicety; showing someone a payment method that cannot complete in their currency is a dead end dressed as a choice.
A decision about what the price is. Is $42 a conversion of your real price, recalculated as rates move, or is it a price you have set in dollars? If it is a conversion, your dollar prices change without anyone deciding, which is unsettling for repeat customers and awkward on a price-comparison page. Most mature stores end up at Level 3 for this reason.
Refund handling. You charged 42 USD when the rate was one thing. You refund six weeks later when it is another. Do you return 42 USD, or the original amount in your own currency? Both are defensible. Only one can be your policy, and it needs to be written on your refund page before a customer asks.
Accounting that can carry it. Revenue recognized in multiple currencies, settlement at a different rate from the sale, provider fees taken in a third. Your accountant has opinions about this and they should be consulted before the build, not after the first quarter.
Honest scoping note: this is where "multi-currency ready" stops being a checkbox. Our e-commerce builds start at $499 over one to five weeks and the store plan lists multi-currency among its features — but which level is in scope needs to be named in the written quote, not assumed. Level 1 is routine. Level 2 changes the payments work, the refund flow and the reporting.
Level 3: market pricing
Here the currencies are not conversions of each other. You charge 199,000 UZS in one market and $29 in another because those are the right prices for those markets, and nobody should be able to derive one from the other.
This is a commercial decision first. The software just has to stop fighting it.
What it takes: a price per product per market, held independently. Rules for which market a visitor belongs to, and what happens when they disagree with your guess. A policy on whether a customer can switch — and the awkward truth that if they can, some of them will buy at the cheaper price, which is either acceptable or not, but must be decided rather than discovered.
When it is right: genuinely different purchasing power, different competitors, different tax treatment, or different cost to serve. If you sell into Uzbekistan and into Western Europe, a single converted price is almost certainly wrong in one of them.
The trap: market pricing plus an unclear currency switcher produces a store where the same customer sees three prices and trusts none of them. If you do this, be deliberate about how the market is chosen and how visible the switch is.
Store money correctly from day one
There is one technical decision that costs nothing at the start and is painful to retrofit, and it applies even if you never go past Level 1.
Store every amount with its currency, as an integer in minor units.
Two parts to that, and both matter.
With its currency. An amount without a currency is not money, it is a number, and a database column called price holding 42.00 is a bug waiting for your second market. Every stored amount — prices, order totals, refunds, discounts, shipping — should carry the currency alongside it.
As an integer in minor units. Store 4200 cents, not 42.00. Decimal arithmetic on floating-point numbers produces small errors that accumulate, and they surface in the worst possible place: a total that is one cent off, a refund that does not match the charge, a reconciliation that will not balance. Integers in the smallest unit remove the entire class of problem.
Two complications worth knowing about before someone assures you this is simple. Not every currency has two decimal places — some have none and a few have three, so "multiply by 100" is not a universal rule. And the number of decimal places is a property of the currency, which is another reason the currency has to travel with the amount rather than being assumed by the application.
None of this is difficult when it is done at the start. All of it is a migration across every table, every report and every historical record when it is done later. If you are commissioning a store now and multi-currency is even a possibility, put this one line in the brief.
Currency is not localization
Three separate things get bundled together and they should be scoped separately:
Currency — what number, in what unit. Language — what words. Locale formatting — decimal separators, thousands separators, date formats, name order.
You can need any one without the others. A single-language store can serve three currencies. A trilingual site can charge in one.
We run Bronjoy in Russian, Uzbek and English, with a standing rule that English leaking onto a Russian or Uzbek page is treated as a bug — every piece of directory vocabulary comes from one shared dictionary rather than being translated where it is used. That discipline is about language, not money, and it is its own line in a scope.
The formatting piece is small and causes disproportionate damage when ignored. A price rendered as 1,299.00 to a reader who writes 1 299,00 reads as a foreign document, and in the worst case as a different number.
Working out which level you need
Four questions.
- Do you want to be paid in another currency, or just understood in one? Understood only is Level 1. Stop there.
- Do your payment providers support the currencies you would charge in, for the methods your customers use? If no, that is the project, and it comes before the currency work. See the payment method you do not offer.
- Should your price in each market be a conversion, or a decision? A decision is Level 3 and it is a pricing exercise, not a development one.
- What does a refund return? If you cannot answer in one sentence, you are not ready for Level 2.
Most businesses that ask us for multi-currency need Level 1, a clear statement of the charging currency, and correct number formatting. That is days of work and it removes the friction they were actually feeling.
The ones who genuinely need Level 2 or 3 usually know it already, because they are being asked for it by customers rather than by a feature list.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Can I start at Level 1 and move up later?
Yes, and it is the sensible path — provided the codebase does not assume one currency everywhere. Ask for money to be stored with its currency from day one, in minor units as integers rather than as decimals. That single decision costs nothing now and is the expensive part to retrofit.
Should I detect the visitor's currency automatically?
Detect, then let them change it, and make the control easy to find. Automatic detection is often wrong — travelers, VPNs, expatriates, anyone buying a gift for someone abroad. Detection as a default is helpful; detection as a rule is a customer who cannot buy.
What exchange rate should I use?
For display, a reputable daily rate with a documented refresh is fine. For charging, use your payment provider's rate for the transaction, because that is the one you will actually be settled at — using your own rate and settling at theirs creates a small permanent leak that nobody notices until the year-end reconciliation.
Does multi-currency affect tax?
It can, significantly, and it varies by jurisdiction and by what you sell. Digital goods in particular have their own rules in several markets. This is a question for an accountant in each market you sell into, and it should be asked before the build rather than after the first return is filed.
Is a currency switcher bad for conversion?
Only when it is confusing. A switcher that is easy to find, remembers the choice, and clearly states what currency the charge will be in helps. One that changes prices unpredictably, or that shows a converted figure without saying the charge is in another currency, is worse than no switcher at all.
