Платёжный оркестратор: несколько эквайрингов на Битрикс

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

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

Что такое платёжный оркестратор

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

Важно не путать оркестратор с одной платёжной системой. Даже большой агрегатор (ЮKassa, CloudPayments, банковский эквайринг) — это по-прежнему один провайдер с одной зоной ответственности и одной точкой отказа. Оркестратор же управляет несколькими такими провайдерами как пулом ресурсов: у каждого свой приоритет, свои условия применения и своё текущее состояние здоровья. Клиент этого не видит — для него это по-прежнему одна кнопка «Оплатить», за которой прячется вся маршрутизация.

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

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

Зачем магазину несколько эквайрингов

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

• Отказоустойчивость. Главная причина. Любой провайдер иногда недоступен — плановые работы, инцидент на его стороне, блокировка со стороны банка-эквайера. Второй провайдер в резерве превращает получасовой простой приёма денег в незаметное переключение.
• Оптимизация комиссии. У разных провайдеров разные тарифы для разных карт и каналов. Оркестратор может по умолчанию вести платёж через самый дешёвый канал, а на дорогих операциях (например, зарубежные карты) переключаться на того, кто их лучше принимает.
• Разные каналы приёма. Один провайдер силён в СБП, другой — в рассрочке и BNPL, третий — в приёме иностранных карт. Собрать всё у одного часто невозможно, и оркестратор аккуратно раздаёт платежи по специализациям.
• Рост доли одобрений. Одна и та же карта у разных эквайеров может проходить с разной вероятностью из-за антифрод-правил. Умная маршрутизация и повторная попытка через другого провайдера поднимают итоговый approval rate.
• Управление рисками и лимитами. Распределение оборота между несколькими банками снижает зависимость от одного контрагента и его лимитов, что критично для крупных магазинов и маркетплейс-моделей.

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

Архитектура: слои и компоненты

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

• Слой заказа. Стандартный заказ 1С-Битрикс с его статусной моделью и коллекцией оплат. Это единый источник правды о том, оплачен заказ или нет, независимо от числа попыток и провайдеров.
• Слой правил (роутер). Логика, которая по параметрам заказа и текущему состоянию провайдеров выбирает, каким эквайрингом вести платёж. Здесь живут приоритеты, условия применения и fallback-цепочки.
• Слой провайдеров (адаптеры). Обработчики платёжных систем — по одному на каждый эквайринг. Каждый адаптер умеет инициировать платёж, принять callback, проверить статус и, при необходимости, сделать возврат.
• Слой здоровья (health-check). Фоновый мониторинг доступности и качества провайдеров: таймауты, коды ошибок, доля отказов. Именно он подсказывает роутеру, кого считать «здоровым».
• Слой транзакций (реестр). Единый журнал всех попыток оплаты со ссылкой на заказ, провайдера, сумму, комиссию, статус и время. Основа сверки и отчётности.
• Слой фискализации. Пробитие чеков по 54-ФЗ на факт оплаты, вынесенное отдельно от конкретного эквайринга.

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

Приоритеты и правила маршрутизации

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

На практике условия маршрутизации собираются из нескольких измерений:

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

Отдельно продумайте цепочку fallback для каждого правила. Приоритет — это не одиночное «кому отдать», а упорядоченный список: сначала A, при недоступности B, затем C. Чем критичнее канал, тем длиннее и надёжнее должна быть цепочка. Для B2B-платежей по счёту, где клиент оплачивает по ссылке на оплату или выставленному счёту, цепочку резервирования особенно важно продумать: такой клиент не будет повторять попытку пять раз, ему нужно, чтобы платёж прошёл с первого раза.

Резервное переключение при сбоях

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

Различают два типа сбоев, и реагировать на них надо по-разному.

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

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

Ещё один нюанс — circuit breaker (предохранитель). Если провайдер начал массово отклонять или отваливаться по таймауту, не имеет смысла упорно слать на него каждый следующий платёж и ждать, пока он сработает failover. Правильнее временно «разомкнуть цепь»: пометить провайдера нездоровым, увести весь трафик на резерв и периодически пробовать, не восстановился ли он. Это снижает и время отклика для клиента, и нагрузку на падающий шлюз.

Health-check и мониторинг провайдеров

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

Что именно стоит измерять:

• Доступность шлюза. Отвечает ли провайдер на служебный запрос в разумное время. Простейший, но не самый показательный сигнал.
• Доля отказов за окно. Сколько процентов платежей за последние N минут завершились технической ошибкой (не отказом эмитента, а именно сбоем на стороне шлюза). Резкий рост — повод разомкнуть цепь.
• Время отклика. Растущие задержки инициализации платежа — ранний признак деградации, часто заметный до полного отказа.
• Approval rate. Доля одобренных платежей. Её падение может говорить и о проблемах провайдера, и о смене антифрод-правил.

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

Идемпотентность и защита от задвоения

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

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

Единый статус заказа означает, что факт оплаты фиксируется в одном месте — на заказе 1С-Битрикс — и именно он определяет, нужно ли вообще принимать деньги. Логика обработки любого callback выглядит так:

1. Пришёл callback от провайдера. Проверяем подпись/аутентичность уведомления — принимаем только доверенные callback-и.
2. Находим заказ и его текущий статус. Если заказ уже оплачен — новый успешный платёж помечаем как избыточный и ставим на возврат либо не захватываем (если была только авторизация без списания).
3. Если заказ ещё не оплачен — применяем платёж. Фиксируем транзакцию, переводим заказ в «оплачен», запускаем фискализацию.
4. Блокируем гонки. Обработку callback-а оборачиваем в блокировку по заказу, чтобы два одновременных уведомления не «прошли» оба.

Отдельного внимания заслуживает сценарий «медленный callback». Клиент не дождался ответа основного провайдера, оркестратор увёл его на резерв, там он оплатил — а через минуту прилетел успешный callback и от первого провайдера. Без описанной логики вы получите двойное списание. С ней — второй платёж корректно распознаётся как избыточный и уходит на автоматический возврат. Именно этот сценарий отличает продуманный оркестратор от опасной самоделки.

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

Теперь конкретика по платформе. 1С-Битрикс даёт всё необходимое, чтобы собрать оркестратор без сторонней шины, если объёмы это оправдывают. Разберём по компонентам.

Платёжные системы. Каждый эквайринг подключается как отдельная платёжная система в модуле «Интернет-магазин» (Магазин → Настройки → Платёжные системы). У каждой — свой обработчик: штатный (для популярных провайдеров они есть из коробки) или пользовательский. Обработчик отвечает за инициализацию платежа, формирование формы/редиректа и приём callback.

Роутер как надстройка. Логику выбора провайдера удобно вынести в отдельный сервисный класс (например, в свой модуль partner.payment), который на этапе оформления заказа или создания оплаты решает, какую платёжную систему подставить. Вызывается он из обработчика события OnSaleOrderSaved или на шаге выбора оплаты в оформлении. Роутер читает правила и статусы провайдеров и проставляет заказу нужную платёжную систему.

Обработчики событий. Ключевые точки — события модуля sale: сохранение заказа, смена статуса оплаты, обработка callback. На них навешиваются: фиксация транзакции в реестре, проверка идемпотентности, запуск failover, инициация фискализации. Регистрируются обработчики штатно, через EventManager в вашем модуле.

Реестр транзакций. Единый журнал удобно хранить в highload-блоке или собственной таблице (через ORM-сущность D7). Поля-минимум: заказ, провайдер, сумма, комиссия, статус, внешний ID транзакции, ключ идемпотентности, время создания и время зачисления. Это основа сверки и отчётов.

Health-check и переиндексация статусов. Реализуется агентом 1С-Битрикс (CAgent) или системным кроном, который раз в минуту-две пересчитывает метрики по реестру и обновляет статусы провайдеров в быстром хранилище (опции модуля, кэш или highload-блок).

Если у вас уже настроены базовые платёжные системы (например, вы прошли подключение ЮKassa, СБП и Т-Кассы), то оркестратор надстраивается поверх них: сами подключения не переделываются, добавляется только слой маршрутизации и учёта.

Как это выглядит в админке

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

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

СБП, рассрочка и специальные каналы

Мультиэквайринг редко бывает «одинаковыми провайдерами про запас». Чаще это разные каналы приёма с разной экономикой, и оркестратор должен уметь их различать. Разберём типовые случаи.

СБП (Система быстрых платежей). Оплата по QR-коду с низкой комиссией — самый экономный канал для многих магазинов. Логично сделать его каналом по умолчанию там, где клиент к нему готов, а карты держать как альтернативу. При этом у СБП свои сценарии возврата и свои коды ошибок, которые health-check должен трактовать отдельно от карточного эквайринга.

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

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

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

Сверка, 54-ФЗ и учёт транзакций

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

Что должен обеспечивать учётный слой оркестратора:

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

Отдельно про 54-ФЗ и чеки. Ключевая рекомендация: не привязывайте фискализацию к конкретному эквайрингу. Чек пробивается на факт получения оплаты, и клиенту всё равно, каким банком она принята. Поэтому фискализацию удобно вынести в отдельный слой — облачную кассу или ОФД, — который получает от оркестратора событие «заказ оплачен на такую-то сумму» и пробивает один чек, независимо от того, сколько попыток и провайдеров было по пути. Это заодно решает риск задвоения чеков: чек привязан к факту оплаты заказа, а не к каждой транзакции.

Сверку удобно автоматизировать: агент забирает выписки/реестры провайдеров (по API или по загруженным файлам) и сопоставляет их с внутренним реестром транзакций, помечая расхождения. Ручная сверка на объёме — источник ошибок и потерянного времени; на мультиэквайринге она масштабируется линейно числу провайдеров, поэтому автоматизация окупается быстро.

Безопасность и PCI DSS

Несколько провайдеров — это несколько точек, через которые проходят платёжные данные, и несколько наборов секретов (ключи API, секреты подписи callback). Безопасность нельзя оставлять на потом.

• Не храните карточные данные у себя. Используйте размещённые платёжные формы провайдеров или токенизацию. Если реквизиты карт не проходят через ваш сервер, требования PCI DSS к вашей инфраструктуре кардинально снижаются. Это базовый и самый важный принцип.
• Проверяйте подпись callback. Каждое уведомление от провайдера должно проходить проверку аутентичности (подпись, IP-фильтр, секрет). Иначе злоумышленник может подделать «успешную оплату» и получить товар бесплатно.
• Разделяйте секреты провайдеров. Ключи каждого эквайринга храните отдельно и вне репозитория (в защищённых настройках, переменных окружения, секрет-хранилище). Компрометация одного не должна открывать доступ к остальным.
• Логируйте, но не логируйте лишнее. В реестр и логи не должны попадать полные номера карт, CVV и прочие чувствительные данные. Логируйте идентификаторы транзакций и статусы, а не платёжные реквизиты.
• Ограничивайте доступ к настройкам оркестратора. Правила маршрутизации и ключи провайдеров — чувствительная зона. Доступ к ней в админке должен быть только у ответственных ролей.

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

Метрики и приёмка

«Оркестратор работает» — субъективное ощущение, пока оно не подкреплено метриками. Чтобы управлять мультиэквайрингом, за ним нужно наблюдать. Вот показатели, на которые стоит смотреть.

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

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

• Строят failover без идемпотентности — при медленном callback клиента списывают дважды, а бухгалтерия потом ищет, кому вернуть деньги.
• Считают провайдера нездоровым по бизнес-отказам эмитента (недостаточно средств) — здоровые эквайринги «ломаются» на ровном месте, трафик зря уходит на резерв.
• Проверяют доступность провайдера синхронно в момент оплаты — оформление заказа замедляется, а шлюзы получают лишнюю нагрузку.
• Забывают про единый реестр транзакций — failover работает, а сверка при закрытии месяца превращается в ручной ад.
• Привязывают чеки 54-ФЗ к конкретному эквайрингу — при переключении провайдера чек либо не пробивается, либо задваивается.
• Не проверяют подпись callback — открывается дыра, через которую можно сымитировать «успешную оплату».
• Резервируют специальные каналы обычным эквайрингом — рассрочку «переключают» на карту, ломая бизнес-логику одобрения.
• Прячут правила маршрутизации в код — любое изменение приоритета требует деплоя, и никто не понимает, почему платёж ушёл именно туда.
• Тестируют только «счастливый путь» — негативные сценарии (падение провайдера, гонки callback) всплывают уже в бою, на живых деньгах.

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

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

1. Провайдеры подключены и протестированы. Каждый эквайринг прошёл интеграцию и боевой платёж отдельно, до включения в оркестрацию.
2. Правила маршрутизации описаны декларативно. Приоритеты, условия и цепочки fallback вынесены в настройки, а не зашиты в код.
3. Идемпотентность реализована. Каждая попытка оплаты несёт ключ идемпотентности, а единый статус заказа блокирует повторное списание.
4. Failover проверен на негативе. Искусственное падение провайдера корректно переводит трафик на резерв без задвоения.
5. Health-check настроен. Фоновый агент считает метрики и обновляет статусы; бизнес-отказы не путаются с техническими сбоями.
6. Реестр транзакций ведётся. По каждому платежу известны провайдер, комиссия, сумма зачисления, статус и связь с заказом.
7. Фискализация вынесена отдельно. Чек пробивается на факт оплаты заказа независимо от провайдера, задвоения чеков нет.
8. Сверка автоматизирована. Выписки провайдеров сопоставляются с внутренним реестром, расхождения подсвечиваются.
9. Безопасность закрыта. Карточные данные не хранятся, callback-и проверяются по подписи, секреты провайдеров разделены.
10. Метрики на дашборде. Approval rate, доля failover, задвоения и расхождения сверки видны и отслеживаются.

Вывод

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