Оплата в Битриксе: платёжные системы, чеки и статусы заказа

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

Какие способы оплаты подключаются к заказу в Битриксе

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

Из коробки в системе уже есть готовые обработчики для популярных сервисов, и я обычно начинаю именно с них, а не с написания своего:

• ЮKassa, для приёма карт и электронных кошельков через один договор
• Робокасса, агрегатор с поддержкой карт, СБП и рассрочки
• эквайринг Сбербанка и эквайринг Т‑Банка, прямое подключение к банку без агрегатора
• PayMaster, ещё один агрегатор способов оплаты
• СБП напрямую через банк-эквайер, без комиссии агрегатора

Часть этих обработчиков идёт в поставке Битрикса, часть ставится отдельным модулем от самого сервиса. Наличный расчёт, безналичный расчёт для юрлиц и оплата при получении настраиваются без интеграции вообще, просто как способ оплаты без обработчика.

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

Подключение эквайринга и платёжных сервисов

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

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

Частая причина, по которой уведомление от платёжной системы не долетает до сайта: обработчик ждёт запрос по HTTPS с действующим сертификатом, а сайт временно работает по HTTP или сертификат просрочен. Второй частый случай, сервер настроен ограничивать входящие запросы по IP, а адреса платёжной системы в белый список не попали.

Онлайн-касса и чек по 54-ФЗ при оплате заказа

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

Первый: платёжный сервис сам передаёт данные для чека в подключённую к нему онлайн-кассу, эта настройка обычно делается в личном кабинете сервиса, а не в Битриксе, от сайта требуется только точно передать состав заказа и цены. Второй: чек формирует отдельная касса, подключённая к Битриксу через обработчик, среди распространённых вариантов АТОЛ Онлайн, CloudKassir, OrangeData. В этом случае в настройках оплаты нужно сопоставить товары с номенклатурой чека и указать ставку НДС для каждой товарной позиции, иначе касса не примет запрос на пробитие чека или пробьёт его с неверной суммой налога.

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

Статусы заказа и как оплата на них влияет

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

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

С каждым статусом можно связать уведомление, письмо покупателю, смс или сообщение в Telegram-бота через вебхук. Такую связку я обычно выношу за пределы самого Битрикса и собираю в n8n, когда уведомлений много и они идут в разные каналы одновременно: отдельный сценарий проще менять, чем правку в шаблонах уведомлений сайта.

Доставка и оплата при работе с СДЭК

Оплату часто привязывают к способу доставки. Например, для доставки СДЭК можно оставить оплату картой заранее на сайте и оплату при получении, если СДЭК передаёт наложенный платёж, а для курьерской доставки по городу, где курьер не принимает карту, оставить только предоплату.

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

Типичные проблемы при настройке оплаты в Битриксе

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

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

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

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

1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.

Частые вопросы

Можно ли принимать оплату через СБП в Битриксе?

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

Нужна ли отдельная касса, если эквайринг уже подключён?

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

Что делать, если статус заказа не меняется после оплаты?

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

Можно ли настроить частичную оплату или предоплату?

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