Трансграничные платежи и мультивалютность в Битрикс

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

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

Зачем магазину трансграничные платежи

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

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

Хорошая новость в том, что 1С-Битрикс изначально спроектирован как мультивалютная платформа. Модуль «Валюты» — часть ядра, торговый каталог умеет хранить цены в разных валютах, а система оплаты построена как набор подключаемых обработчиков. Плохая новость — что «из коробки» всё это настроено под одну страну и одну валюту, и трансграничный сценарий приходится собирать осознанно, разводя понятия, которые новичок обычно путает.

Валюта, витрина и расчёт — три разные вещи

Главная путаница трансграничных проектов — смешение трёх разных «валют», которые на самом деле живут на разных уровнях. Разведите их в голове раз и навсегда, и половина вопросов отпадёт сама.

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

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

Базовая валюта и мультивалютность в Битриксе

Технически мультивалютность в 1С-Битрикс держится на модуле «Валюты» (currency) и на связке с торговым каталогом. Разберём по слоям, что за что отвечает.

Модуль «Валюты». Здесь заводятся все валюты магазина, их форматы вывода (символ, разделители, число знаков) и курсы относительно базовой. Одна валюта помечается как базовая — это точка отсчёта для всех пересчётов и для учёта. Курсы можно вводить вручную, загружать по расписанию с сайта ЦБ или из внешнего источника через агент.

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

Валюта заказа. Заказ оформляется в валюте, которую видит покупатель, и в нём сохраняется как сама сумма, так и валюта. Это критично: заказ должен «помнить» свою валюту и курс, а не пересчитываться каждый раз по текущему курсу.

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

Курсы и конвертация: динамика против фиксированных цен

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

Динамический пересчёт по курсу. Цена хранится только в базовой валюте, а во всех остальных считается на лету по текущему курсу. Плюс — не нужно вести несколько прайсов, цена «сама» следует за курсом. Минус — она скачет каждый день, покупатель видит некруглые суммы вроде «84,37 €», а при падении курса вы можете уйти в минус по марже, если не заложили запас.

Фиксированные цены (ценовые пояса). Для каждой валюты задаётся отдельная цена вручную, обычно круглая и психологически удобная («89 €» вместо «84,37 €»). Плюс — предсказуемость выручки, красивые цены, независимость от дневных колебаний. Минус — прайсы надо поддерживать и периодически переоценивать, а при резком движении курса цена на рынке может временно оторваться от базовой.

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

Ценообразование под разные рынки

Валюта — только обёртка. За ней стоит более важный вопрос: сколько вообще должен стоить товар на конкретном рынке. Механический пересчёт «рублёвая цена × курс» почти всегда даёт неконкурентную или, наоборот, убыточную цену, потому что не учитывает местную покупательную способность, логистику, пошлины и уровень цен конкурентов.

Поэтому мультивалютность на зрелом проекте почти всегда идёт в связке с рыночным ценообразованием:

• Отдельный прайс на рынок. Для каждого целевого региона заводится свой тип цены, и цена в нём назначается исходя из местного рынка, а не из курса.
• Учёт логистики и пошлин в цене. Если доставка и таможня велики, их либо закладывают в цену товара, либо выносят в отдельную строку — но покупатель должен видеть итоговую сумму без сюрпризов на границе.
• Психологические цены в местной валюте. «99 $», «89 €», а не арифметический результат конвертации. Это прямо влияет на конверсию.
• Разные наборы товаров на рынках. Иногда часть ассортимента на рынок просто не выводят — из-за сертификации, пошлин или отсутствия спроса.

Стратегическую сторону выхода на новые рынки — от юрлица и логистики до локализации витрины — мы разбираем в материале международная экспансия магазина на Битрикс. Ценообразование и платежи — это уже операционный слой той же задачи.

Налоги, НДС и таможня при экспорте

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

Грубая, но полезная карта ситуаций:

Из этого вытекает главное правило настройки: ставку НДС нельзя жёстко прибивать к товару. Один и тот же товар для покупателя из своей страны и на экспорт должен облагаться по-разному. Значит, налог должен вычисляться из связки «тип покупателя + страна назначения + тип товара», а не быть фиксированным свойством карточки.

Отдельно держите в голове таможню и пошлины на стороне покупателя. Если товар приходит с неожиданной пошлиной «на пороге», покупатель воспринимает это как обман магазина, даже если формально виноват не продавец. Прозрачно показывайте, включены пошлины в цену (модель DDP — оплачено продавцом) или ложатся на получателя (DAP), — это часть честного трансграничного оформления заказа.

Платёжные провайдеры для приёма из-за рубежа

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

• Российский эквайринг (ЮKassa, Тинькофф, Сбер и т. п.). Отлично принимает карты российских банков и рубли. Карты иностранных банков и валюты кроме рубля через него проходят ограниченно или не проходят вовсе — это не для трансграничного приёма.
• Международные PSP. Провайдеры, заточенные под приём карт множества стран и валют. Требуют, как правило, юрлица в соответствующей юрисдикции и прохождения проверки бизнеса.
• Локальные методы оплаты. В каждой стране есть свои привычные способы платить, помимо карт: местные кошельки, банковские переводы, рассрочки. Без них конверсия на рынке проседает.
• Расчёты через иностранное юрлицо. Для устойчивого трансграничного потока часто выстраивают отдельную юридическую структуру, через которую и идёт приём. Это не задача сайта, но именно она определяет, какого провайдера вы вообще сможете подключить.

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

Локальные методы оплаты и география

Карта Visa/Mastercard — привычный для нас способ, но далеко не универсальный. В части стран доля карточных платежей в онлайне невелика, и покупатели ожидают увидеть свой локальный способ: местный кошелёк, банковский онлайн-перевод, оплату по QR, рассрочку у местного провайдера. Если такого метода на витрине нет, покупатель просто уходит, даже если товар и цена его устроили.

Отсюда практическое правило: набор способов оплаты должен зависеть от страны покупателя. В 1С-Битрикс это решается привязкой платёжных систем к свойствам заказа — стране доставки, валюте, типу плательщика. Покупателю из одной страны показываются карты и локальный кошелёк, из другой — карты и банковский перевод, из третьей — только то, что реально работает в его регионе.

Не менее важна и обратная сторона — не показывать методы, которые для покупателя нерелевантны. Длинный список из десяти способов оплаты, половина из которых в его стране не работает, снижает доверие и увеличивает число неудачных попыток. Лучше два-три релевантных метода, чем десять «на всякий случай».

Отказы, 3-D Secure и антифрод

Первое, к чему нужно привыкнуть в трансграничных платежах: отказ — это норма, а не поломка. Доля неуспешных попыток по международным картам заметно выше, чем по внутренним, и причины лежат вне вашего сайта. Понимание источников отказа помогает не паниковать и не «чинить» то, что не сломано.

• Банк-эмитент. Самая частая причина. Антифрод банка покупателя блокирует «подозрительную» зарубежную операцию, срабатывают лимиты или запрет на онлайн-платежи за рубеж.
• 3-D Secure. Покупатель не прошёл подтверждение (не пришёл код, отменил, истекло время). Формально оплата не состоялась, хотя карта рабочая.
• Провайдер. PSP не поддерживает валюту, страну карты или тип операции — платёж отклоняется на его стороне.
• Антифрод продавца. Ваши собственные правила против мошенничества могут ошибочно резать легитимные заказы, если настроены слишком жёстко.

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

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

Оркестрация нескольких эквайрингов

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

Что даёт оркестрация на практике:

• Резерв при сбое. Если основной провайдер недоступен или отклонил платёж, покупателю тут же предлагается второй маршрут — без потери заказа.
• Маршрутизация по географии и валюте. Платёж отправляется тому провайдеру, который лучше проводит операции конкретной страны или валюты.
• Оптимизация комиссии. Разные провайдеры берут разную комиссию за разные типы операций; правила маршрутизации помогают экономить.
• Единая аналитика. Сбор статистики отказов по провайдерам, странам и кодам ошибок в одном месте — база для дальнейшей настройки.

Архитектуру и настройку такой схемы в 1С-Битрикс мы отдельно разбираем в статье платёжный оркестратор: несколько эквайрингов на Битрикс. Для трансграничного сценария оркестрация особенно ценна: именно здесь доля отказов высока, а каждый спасённый платёж — это реальная зарубежная выручка, которую иначе вы бы потеряли.

Реализация в 1С-Битрикс

Соберём всё в конкретную последовательность настройки. Ниже — практический маршрут внедрения трансграничного приёма в магазине на 1С-Битрикс. Точные названия пунктов зависят от версии и редакции платформы, но логика общая.

1. Определите базовую валюту и зафиксируйте её. В модуле «Валюты» проверьте, что базовая валюта совпадает с валютой вашего учёта. На новом проекте это делается один раз до наполнения каталога.
2. Заведите валюты витрины и курсы. Добавьте нужные валюты (EUR, USD, локальные), настройте формат вывода и источник курса. Для динамики подключите автоматическую загрузку курса агентом, для фиксированных цен курс нужен только для служебных пересчётов.
3. Создайте типы цен под рынки. Для фиксированного ценообразования заведите отдельные типы цен (например, «Розница EUR», «Розница USD») и назначьте цены вручную. Свяжите видимость типа цены с регионом или языком витрины.
4. Настройте налоговую матрицу. Свяжите ставку НДС не с товаром напрямую, а со свойствами заказа: тип плательщика (физлицо/юрлицо), страна доставки, тип товара. Реализуется через свойства заказа и правила расчёта корзины.
5. Подключите платёжные системы. В разделе «Магазин → Платёжные системы» добавьте обработчики нужных провайдеров. Для нестандартных международных PSP чаще всего требуется собственный обработчик оплаты — это и есть основная работа по интеграции.
6. Привяжите способы оплаты к географии. Настройте ограничения платёжных систем по стране, валюте и типу плательщика, чтобы покупатель видел только релевантные для него методы.
7. Заложите резервный маршрут. Подключите минимум двух провайдеров и настройте переключение на резерв при отказе — самостоятельно или через слой оркестрации.
8. Настройте фиксацию курса в заказе. Убедитесь, что заказ сохраняет свою валюту, сумму и применённый курс на момент оформления и не пересчитывается задним числом.
9. Проверьте сквозной сценарий. Проведите тестовые заказы из разных стран в разных валютах, проверьте корректность цены, налога, способа оплаты и итоговой суммы, а также поведение при отказе оплаты.

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

Учёт, возвраты и фиксация курса в заказе

Трансграничный заказ не заканчивается успешной оплатой — дальше начинается его жизнь в учёте, а иногда и возврат. И здесь важнее всего одно правило: заказ должен помнить свою валюту и курс. Не текущий курс, а тот, что действовал в момент оформления.

Почему это критично:

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

В 1С-Битрикс это решается тем, что заказ хранит собственную валюту и сумму, а применённый курс и сумму в базовой валюте разумно сохранять как дополнительные реквизиты (свойства) заказа на момент оформления. Возвраты тогда идут в валюте заказа и по его курсу, а бухгалтерия получает достоверную картину.

Частые ошибки

• Путают базовую валюту с валютой витрины и меняют базовую на живом магазине — это ломает учёт, скидки и все прошлые заказы.
• Пересчитывают цену «голым» курсом ЦБ без наценки на курсовой риск и комиссию конвертации — маржа утекает на каждом заказе.
• Жёстко прибивают ставку НДС к товару, из-за чего экспортный заказ уходит с внутренним налогом или наоборот.
• Подключают только российский эквайринг и удивляются, почему иностранные карты не проходят.
• Показывают всем покупателям один и тот же способ оплаты, игнорируя привычные локальные методы стран-получателей.
• Не закладывают резервный маршрут оплаты — единичный отказ провайдера превращается в потерянный заказ.
• Не фиксируют валюту и курс в заказе, из-за чего возвраты и бухгалтерия считаются по текущему, а не по историческому курсу.
• Забывают про сверку с выгрузкой провайдера — расхождения по комиссиям и курсам накапливаются и всплывают в отчётный период.

Чек-лист внедрения

Практический список, по которому удобно принимать готовность трансграничного приёма перед запуском:

1. Юридическая схема согласована. Определено юрлицо и юрисдикция приёма, валютный счёт открыт, схема расчётов подтверждена с юристом и бухгалтером.
2. Базовая валюта зафиксирована. Совпадает с валютой учёта, менять её не планируется.
3. Валюты и курсы настроены. Заведены валюты витрины, выбран подход (динамика или фиксированные цены), источник курса подключён.
4. Ценообразование по рынкам. Для приоритетных рынков заданы цены с учётом местного уровня, логистики и пошлин, а не механический пересчёт по курсу.
5. Налоговая матрица работает. НДС вычисляется из связки «покупатель + страна + тип товара», проверен на тестовых заказах.
6. Провайдеры подключены. Международный эквайринг и релевантные локальные методы работают, привязаны к географии и валюте.
7. Резерв и оркестрация. Есть минимум два маршрута оплаты и автоматическое переключение при отказе.
8. Фиксация курса и сверка. Заказ хранит валюту, сумму и курс на момент оформления; настроена регулярная сверка с выгрузкой провайдера.

Вывод

Трансграничный приём в 1С-Битрикс собирается из трёх связанных слоёв: правильно разведённых валют (учёт, витрина, расчёт), корректной налоговой матрицы под каждый рынок и надёжного платёжного контура с резервом и фиксацией курса в заказе. Ни один из слоёв нельзя пропустить: ошибка в валюте бьёт по марже, ошибка в налоге — по закону, ошибка в провайдере — по конверсии. Настройте все три осознанно — и зарубежные заказы станут не праздником с отказами, а предсказуемым каналом выручки.