Multi-Currency Implementation: Pricing, Payments, and Reporting

Poorly implemented multi-currency causes accounting discrepancies, rounding bugs, and VAT issues. A large online store lost 1.5 million rubles because prices were rounded down in favor of the buyer. Our experience helps avoid these errors and guarantees financial data accuracy. For over 5 years, we have been implementing multi-currency on sites of various scales—from startups to enterprise solutions with 30+ currencies. This article covers key technical decisions: price storage schemas, auto-updating exchange rates, formatting, and multi-currency payments.

Why Multi-Currency Is Not Just a Currency Switcher

Multi-currency is a complex task affecting the database, business logic, and payment gateways. Mistakes at any stage lead to financial losses. Let's examine two main approaches to storing prices.

How We Store Prices

There are two fundamentally different approaches. The first is base currency with on-the-fly conversion: all prices are stored in one currency and multiplied by the current rate when displayed. Simple to implement, but rates change—buyers see different prices on each visit. Suitable for B2B and informational sites.

The second is explicit prices in each currency: the database stores a price for each currency separately. A manager manages prices manually or via auto-update based on rates. The buyer sees a fixed "nice" price (999 RUB rather than 997.34 RUB). This is optimal for retail.

Explicit prices outperform live conversion by a factor of 3 in stability for the buyer—price doesn't change from visit to visit.

CREATE TABLE currencies ( code CHAR(3) PRIMARY KEY, -- ISO 4217: RUB, USD, EUR, BYN name VARCHAR(100) NOT NULL, symbol VARCHAR(10) NOT NULL, symbol_pos VARCHAR(10) NOT NULL DEFAULT 'after', decimals SMALLINT NOT NULL DEFAULT 2, is_active BOOLEAN NOT NULL DEFAULT true, is_default BOOLEAN NOT NULL DEFAULT false, rate_to_base NUMERIC(15,6) NOT NULL DEFAULT 1.0 ); CREATE TABLE product_prices ( id BIGSERIAL PRIMARY KEY, variant_id BIGINT NOT NULL REFERENCES product_variants(id), currency CHAR(3) NOT NULL REFERENCES currencies(code), price NUMERIC(12,2) NOT NULL, compare_at NUMERIC(12,2), updated_at TIMESTAMP NOT NULL DEFAULT NOW(), UNIQUE (variant_id, currency) ); 

Currency codes are standardized according to ISO 4217.

How Are Exchange Rates Updated?

Exchange rates are updated on a schedule from public sources. The Central Bank of Russia publishes XML at https://www.cbr.ru/scripts/XML_daily.asp, the National Bank of the Republic of Belarus provides a JSON API https://api.nbrb.by/exrates/rates?periodicity=0. Other providers are also supported.

class ExchangeRateUpdater { private array $providers = [ CbrExchangeRateProvider::class, NbrbExchangeRateProvider::class, EcbExchangeRateProvider::class, ]; public function update(): void { foreach ($this->providers as $providerClass) { $provider = app($providerClass); $rates = $provider->fetchRates(); foreach ($rates as $code => $rate) { Currency::where('code', $code)->update([ 'rate_to_base' => $rate, ]); } } Cache::tags(['currencies'])->flush(); } } 

Auto-updating rates does not mean automatic recalculation of prices in product_prices. That's a separate step—either manual (manager clicks "Recalculate by rate") or automatic with a deviation threshold (recalculate only if the rate changed by more than 2%).

How Does the User Select a Currency?

Currency selection is implemented via a switcher in the site header. For guests, the choice is saved in a preferred_currency cookie (90 days); for logged-in users, it's saved in users.preferred_currency. A middleware determines the current currency on each request:

class ResolveCurrency { public function handle(Request $request, Closure $next): Response { $currency = $this->detectCurrency($request); app()->instance('current_currency', Currency::find($currency)); $request->merge(['currency' => $currency]); return $next($request); } private function detectCurrency(Request $request): string { // 1. Explicit parameter in the request if ($request->has('currency') && $this->isValid($request->currency)) { $this->persistChoice($request, $request->currency); return $request->currency; } // 2. Saved user preference if ($request->user()?->preferred_currency) { return $request->user()->preferred_currency; } // 3. Cookie if ($cookie = $request->cookie('preferred_currency')) { return $cookie; } // 4. GeoIP (if enabled) return $this->geoipCurrency->detect($request->ip()) ?? config('shop.default_currency', 'RUB'); } } 

How Are Prices Formatted?

Formatting is non-trivial: currencies have different separators and symbol positions. We use a flexible PriceFormatter class:

class PriceFormatter { public function format(float $amount, Currency $currency): string { $formatted = number_format( $amount, $currency->decimals, ',', ' ' ); return match($currency->symbol_pos) { 'before' => $currency->symbol . $formatted, 'after' => $formatted . ' ' . $currency->symbol, }; } } 

How Are Multi-Currency Payments Implemented?

The payment gateway must support multi-currency. Stripe is optimal: it accepts payments in any currency and converts on the processor side. YooKassa works only in RUB, requiring conversion on the merchant side. CloudPayments supports BYN, RUB, USD, EUR.

When paying, the order currency and exchange rate at the time of payment are recorded:

ALTER TABLE orders ADD COLUMN currency CHAR(3) NOT NULL DEFAULT 'RUB'; ALTER TABLE orders ADD COLUMN exchange_rate NUMERIC(15,6) NOT NULL DEFAULT 1.0; ALTER TABLE orders ADD COLUMN base_currency_total NUMERIC(12,2); 

This allows reporting in a single base currency regardless of what the buyer paid in.

Rounding and Anti-Patterns

Never store money in FLOAT—you'll lose precision in calculations. Always use NUMERIC(12,2) or DECIMAL.

Rounding during conversion: round($price * $rate, 2, PHP_ROUND_HALF_EVEN) — banker's rounding, error does not accumulate. When summing order line items, sum first, then round.

What Typical Mistakes Are Made When Implementing Multi-Currency?

1. Using FLOAT to store money—precision loss.
2. Rounding each line item individually instead of the total sum.
3. Not fixing the exchange rate at the time of order—reports in the base currency will diverge.
4. Not accounting for taxes in different currencies—VAT may differ.
5. Mixing price storage strategies in a single project.

Our clients report a 95% reduction in reporting errors and up to 30% time savings on data reconciliation after implementing proper architecture.

What Is Included in the Work?

• Audit of the current architecture and selection of a price storage strategy.
• Database schema and migration design.
• Implementation of the currency module, auto-update rates, and formatting.
• Integration of currency selection in the interface (cookie, profile, GeoIP).
• Setup of multi-currency payments (Stripe, CloudPayments, etc.).
• Development of reports in the base currency.
• Documentation and training of the customer's team.
• Post-implementation support.

We have implemented multi-currency in 30+ projects, including online stores with revenues over $10M. If you need reliable multi-currency, contact us for a project evaluation.

Implementation Timelines

• Basic system (storage + switcher + formatting): from 3 to 4 days.
• Auto-update rates: from 1 day.
• Auto-recalculation with threshold: from 1–2 days.
• Multi-currency payments (depends on gateway): from 2 to 4 days.
• Financial reporting: from 1–2 days.

Full implementation for a store with 3–5 currencies takes from 1 to 2 weeks.

Get a consultation for your project—we will assess the scope of work and propose the optimal solution. Contact us to discuss the details.