Мультивалютный интернет-магазин: как развести валюты отображения, расчёта и платежа

Мультивалютный интернет-магазин — это не переключатель в шапке, а согласованная модель из трёх уровней: валюта отображения цены, валюта расчёта заказа и валюта платежа. Если уровни не развести, покупатель видит одну сумму, в заказе сохраняется другая, а в платёжной системе проходит третья. Ниже — как выбрать рабочую модель, где появляются расхождения при округлении и возвратах, какие данные подготовить для оценки и как принять работу по проверяемым признакам.

Что решает мультивалютный интернет-магазин и где границы задачи

Задача бизнеса обычно формулируется коротко: покупатель из другой страны должен понимать цену и не бросать корзину на этапе оформления. За этим стоят три практические цели: показать цену в привычной покупателю валюте, корректно посчитать итог заказа и провести платёж так, чтобы бухгалтерия и платёжный провайдер сошлись в цифрах.

Мультивалютный интернет-магазин решает ещё одну, менее очевидную задачу — снижает ручную работу. Когда правила пересчёта и фиксации курса описаны, менеджеру не нужно пересчитывать суммы вручную и объяснять покупателю расхождения. Когда правил нет, каждая спорная ситуация закрывается перепиской и правкой цифр.

Границы задачи стоит очертить сразу, иначе проект расползётся.

• Мультивалютность — не то же самое, что мультиязычность. Язык интерфейса и валюта цены — независимые настройки, хотя на практике их часто связывают.
• Мультивалютность — не то же самое, что несколько складов и разные условия доставки. Это отдельная тема про логистику и остатки.
• Мультивалютность — не то же самое, что возвраты. Возврат в валюте заказа — лишь один из сценариев, который нужно описать отдельно.
• Мультивалютность — не то же самое, что приём платежей в любой валюте. Витрина и платёжный контур живут по разным правилам.

Если магазин только планируется, валютную логику дешевле закладывать на этапе разработки интернет-магазина, а не прикручивать поверх готового каталога. Переделка модели хранения цен затрагивает каталог, корзину, заказы, платёжные обработчики и выгрузки в учётную систему — это почти всегда дороже, чем кажется на старте.

Валюта отображения, валюта расчёта и валюта платежа

Три сущности, которые нельзя смешивать. Разберём каждую отдельно.

Валюта отображения

Это то, что покупатель видит на карточке товара, в каталоге и в корзине. Она может быть любой: покупатель выбирает её в переключателе, или она определяется автоматически по региону. Важно, что валюта отображения — это представление, а не обязательство продать по этой сумме. Если цена пересчитывается на лету, её значение меняется вместе с курсом.

Валюта расчёта заказа

Это валюта, в которой заказ фиксируется как финансовый документ. Именно она попадает в счёт, в выгрузку и в бухгалтерию. Ключевое требование: валюта расчёта и сумма в ней должны фиксироваться в момент оформления заказа и больше не меняться от колебаний курса. Иначе один и тот же заказ будет «стоить» по-разному в зависимости от дня просмотра.

Валюта платежа

Это валюта, в которой деньги реально списываются через платёжный провайдер. Она зависит не от желания магазина, а от возможностей конкретного провайдера и правил расчётов в юрисдикции продавца и покупателя. Технически поддержка платежа в выбранной валюте — это отдельная доработка платёжного обработчика, который передаёт валюту по правилам платёжной системы, а не галочка в настройках. В отраслевых обсуждениях это отмечают как самостоятельный блок работ.

Отсюда практический вывод: селектор валют на витрине и возможность оплатить в выбранной валюте — две разные задачи с разной стоимостью. Их нужно разделять в постановке, иначе оценка получится заниженной, а ожидания — завышенными.

Матрица валютных сценариев

Прежде чем оценивать работы, зафиксируйте, какой сценарий нужен бизнесу. Ниже — рабочая матрица, которую можно заполнить под свой проект.

Матрица нужна не для отчётности, а чтобы до начала работ увидеть, сколько разных логик придётся поддерживать. Каждая дополнительная строка — это отдельные проверки, отдельные тесты и отдельные вопросы к бухгалтерии. Если строк получается больше трёх, стоит подумать, нельзя ли сократить набор сценариев: иногда достаточно показывать цену в двух валютах, а расчёты вести в одной.

Курсы, округление и пересчёт

Здесь появляется большинство расхождений, которые потом всплывают в сверках.

Откуда берётся курс

Курс может быть внешним — загружаться из справочника или учётной системы — либо задаваться вручную. Практический вопрос не в источнике, а в том, кто отвечает за его актуальность и что происходит, если курс не обновился. Если пересчёт зависит от курса, стоит заранее решить, что показывать покупателю при отсутствии свежего значения: последний известный курс, базовую цену или сообщение о недоступности.

Где фиксируется курс

Курс нужно фиксировать в момент оформления заказа и хранить вместе с заказом. Тогда при разборе спорной ситуации видно, по какому курсу считалась сумма. Если курс не сохраняется, а пересчитывается при каждом открытии заказа, любые сверки превращаются в догадки.

Округление

Округление — источник мелких, но неприятных расхождений. Нужно определить: округляется ли цена отдельного товара или только итог корзины; до скольких знаков; в какую сторону. Если округлять каждую позицию, сумма позиций может не совпасть с итогом, посчитанным от общей суммы. Это не ошибка сама по себе, но это нужно зафиксировать как правило и проверить на тестовых данных.

Отдельно стоит решить, как ведёт себя цена при смене валюты покупателем: пересчитывается ли она каждый раз заново или берётся из сохранённого значения. Оба варианта допустимы, но они дают разный результат, и выбрать нужно осознанно.

Пересчёт и кэширование

В отраслевых обсуждениях встречается подход, при котором цена хранится в исходной валюте без форматирования, а пересчёт и форматирование выполняются на стороне браузера. Причина — кэширование: если цена в валюте покупателя попадает в кэшируемую часть страницы, число вариантов кэша растёт вместе с числом валют. Пересчёт на клиенте снимает эту нагрузку, но переносит часть логики на устройство покупателя: при отключённых скриптах он увидит неотформатированную цену. Решение о таком подходе принимается с учётом требований к доступности и к отображению.

Для сравнения и сортировки товаров, цены которых заведены в разных валютах, в обсуждениях описывают и другой приём: хранить дополнительное поле с ценой, приведённой к единой валюте, и пересчитывать его при сохранении товара и по расписанию. Тогда сортировка идёт по приведённому значению, а покупателю показывается цена в его валюте. Это не единственный вариант, но он показывает главную мысль: сравнивать и сортировать можно только величины, приведённые к одной валюте.

Возвраты, обмен и частичные операции

Возврат в мультивалютном магазине — это не просто «минус сумма». Нужно ответить на несколько вопросов.

• В какой валюте возвращаются деньги: в валюте платежа или в валюте заказа?
• По какому курсу считается возврат, если между оплатой и возвратом курс изменился?
• Как оформляется частичный возврат, когда из заказа возвращается одна позиция?
• Что происходит с комиссиями провайдера при возврате в другой валюте?
• Как эта операция отражается в выгрузке и в учёте?

Курсовые разницы между оплатой и возвратом — это отдельный сюжет, который относится к учёту и требует сверки с бухгалтерией, а не только с разработчиком. Технически магазин может корректно провести операцию, но учётный результат всё равно нужно согласовать с профильным специалистом.

Практическое правило: сценарии возврата описываются до запуска, а не после первого обращения покупателя. Если возврат в валюте платежа невозможен, это должно быть написано в правилах магазина понятным языком — до того, как покупатель оформит заказ.

Учебный пример: магазин с тремя валютами

Учебный пример. Данные условные, это не реальный проект и не статистика.

Входные условия. Интернет-магазин электроники продаёт товары в трёх валютах: базовая валюта магазина — условная единица A, покупателям показываются также валюты B и C. Каталог содержит 400 позиций, цены заведены в базовой валюте. Покупатель может переключить валюту отображения. Заказ оформляется в валюте отображения, платёж проходит в базовой валюте. Курсы обновляются раз в сутки из учётной системы.

Что делаем по шагам.

1. Фиксируем правило: цена товара хранится в базовой валюте, а в валютах B и C рассчитывается по курсу на момент показа. 2. Определяем, что при оформлении заказа в валюте B сумма заказа сохраняется в валюте B вместе с курсом, который действовал в этот момент. 3. Проверяем, что платёж в базовой валюте соответствует сохранённой сумме заказа по зафиксированному курсу. 4. Описываем сценарий возврата: возврат идёт в базовой валюте по курсу, зафиксированному в заказе, либо по правилу, согласованному с бухгалтерией. 5. Задаём правило округления: цена позиции округляется до двух знаков, итог считается от округлённых позиций. 6. Описываем поведение при недоступном курсе: показываем последнее известное значение и помечаем его как неактуальное.

Проверка. Берём три тестовых заказа: один в базовой валюте, один в валюте B, один в валюте C. Для каждого сверяем пять величин: сумму позиций, итог корзины, сумму в заказе, сумму в платёжной операции и сумму в выгрузке. Отдельно проверяем заказ, оформленный до обновления курса и оплаченный после: сумма не должна измениться. Затем проверяем частичный возврат одной позиции и убеждаемся, что итог заказа после возврата сходится с ожидаемым.

Наблюдаемый результат. Все пять сумм по каждому заказу совпадают, курс в заказе зафиксирован, возврат считается по заранее описанному правилу. Если хотя бы одна сумма расходится, ищем причину в округлении или в моменте фиксации курса, а не «подгоняем» цифры вручную.

Ответственный. За валютную модель отвечает аналитик или руководитель проекта со стороны заказчика; за реализацию — разработчик; за учётный результат — бухгалтерия. Без явного владельца решения расхождения будут закрывать вручную.

Как проверить результат и принять работу

Приёмка мультивалютной логики — это набор воспроизводимых проверок, а не «посмотрели, вроде работает». Ниже чек-лист, который можно использовать как основу.

• Определены и записаны все три валюты: отображения, расчёта и платежа.
• Для каждого сценария из матрицы есть тестовый заказ.
• Курс фиксируется в заказе и виден при разборе.
• Правило округления описано и проверено на позиции и на итоге.
• Сумма заказа не меняется после обновления курса.
• Смена валюты отображения не меняет уже оформленный заказ.
• Возврат полный и частичный проверены на тестовых заказах.
• Поведение при недоступном или устаревшем курсе описано и проверено.
• Выгрузка в учётную систему сходится с заказом по сумме и валюте.
• Правила магазина объясняют покупателю, в какой валюте проходит оплата и возврат.

Если магазин уже работает, часть этих пунктов проверяется в рамках аудита интернет-магазина — что проверяют и что будет в отчёте. Аудит не заменяет доработку, но показывает, где логика расходится с фактическим поведением.

Типичные ошибки и ограничения

• Смешивание валюты отображения и валюты расчёта. Покупатель видит одну сумму, в заказе сохраняется другая.
• Пересчёт цены оформленного заказа при каждом открытии. Сумма «плывёт» вместе с курсом.
• Округление каждой позиции без проверки итога. Расхождение на копейки превращается в спорную сверку.
• Сортировка и фильтрация товаров по цене без приведения к одной валюте. Сравнение становится бессмысленным, если цены заведены в разных валютах.
• Обещание оплаты в любой валюте без проверки возможностей провайдера и правил расчётов.
• Отсутствие описанного сценария возврата до запуска.
• Ручная правка сумм при расхождениях вместо поиска причины.
• Отсутствие владельца решения: правила меняются от случая к случаю.

Ограничения тоже стоит назвать честно. Не каждый платёжный провайдер поддерживает нужную валюту. Порядок расчётов с покупателем и валютный контроль зависят от юрисдикции и требуют сверки с профильным специалистом — это не задача веб-студии. Курсовые разницы и их учёт — зона бухгалтерии. Наконец, чем больше валют и сценариев, тем больше комбинаций для тестирования, и это влияет на объём работ.

Какие исходные данные подготовить для оценки

Чтобы получить внятную оценку, а не диапазон «от и до», подготовьте следующее.

• Список валют: какие показываем, в какой считаем, в какой принимаем оплату.
• Источник курсов и периодичность обновления.
• Правило округления и момент фиксации курса.
• Сценарии возврата: полный, частичный, в какой валюте.
• Список платёжных провайдеров и поддерживаемые ими валюты.
• Требования бухгалтерии к выгрузке заказов.
• Текущая модель хранения цен: в одной валюте или в разных.
• Ожидаемое поведение при недоступном курсе.
• Требования к отображению, если часть пересчёта планируется на стороне покупателя.

Чем конкретнее этот список, тем точнее оценка. Общие ориентиры по составу работ и факторам цены собраны в материале Сколько стоит разработка интернет-магазина: из чего складывается цена — он помогает понять, какие блоки вообще попадают в смету.

Кто отвечает за валютную логику

У мультивалютного магазина несколько владельцев, и это нормально, если роли разделены.

• Бизнес-владелец решает, какие валюты нужны и зачем.
• Аналитик или руководитель проекта описывает сценарии и правила.
• Разработчик реализует хранение, пересчёт и передачу данных в платёжный обработчик.
• Бухгалтерия подтверждает учётный результат и требования к документам.
• Профильный специалист по расчётам и валютному регулированию проверяет юридическую сторону.

Если эти роли не разделены, решения принимаются по умолчанию — обычно в пользу самого простого варианта, который потом не совпадает с ожиданиями бухгалтерии или покупателя. Полезно зафиксировать ответственного письменно: кто подтверждает правило округления, кто — сценарий возврата, кто — перечень валют. Тогда при расхождении понятно, к кому идти с вопросом, а не с кем спорить.