Платежи и доставка в Битрикс: что выбрать магазину

Неправильный выбор платёжной и транспортной интеграции в 1С-Битрикс превращает оформление заказа в цепочку ручных проверок: платёж прошёл, статус не обновился, трек-номер не записался, заказ завис в промежуточном состоянии. Для большинства магазинов на ветках 1С-Битрикс: Управление сайтом 24.x–25.x выбор сводится к трём схемам: штатные обработчики, единый агрегатор или собственные интеграции с каждым провайдером. Разница не только в комиссии. Она определяет, кто отвечает за вебхуки, возвраты, чеки, расчёт доставки и восстановление заказа после сбоя.

Что именно нужно выбрать

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

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

• какие способы оплаты будут видны конкретному типу плательщика и региону;
• кто принимает деньги и отправляет уведомления о статусах;
• как рассчитывается доставка: фиксированно, по тарифу перевозчика или через агрегатор;
• где создаются чеки, накладные, трек-номер и статусы отгрузки.

Версия и терминология. Материал рассчитан на 1С-Битрикс: Управление сайтом 24.x–25.x. Названия пунктов административного раздела могут отличаться в зависимости от редакции, установленного модуля «Интернет-магазин» и подключённых обработчиков.

Сноска. Вебхук — HTTP-уведомление, которое внешний сервис отправляет на адрес магазина после события: успешной оплаты, возврата, смены статуса доставки или создания отправления.

Три архитектуры подключения

1. Штатные обработчики Битрикс

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

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

Такой вариант подходит, если у магазина один-два способа оплаты, типовые тарифы доставки и нет сложного маршрута заказа. Перед установкой проверьте дату обновления модуля, поддержку вашей версии Битрикс, список событий, возвраты и работу в тестовом режиме.

2. Агрегатор платежей и доставки

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

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

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

3. Прямые интеграции и собственный обработчик

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

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

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

Как устроить оплату в заказе

Начните не с установки модуля, а с карты состояний. Для каждого способа оплаты зафиксируйте, что происходит после создания заказа, перехода на страницу провайдера, успешной оплаты, отмены и возврата.

1. Разделите тестовую и боевую среду. Для тестового магазина используйте отдельные ключи и учётные данные провайдера. Боевую оплату нельзя проверять случайным заказом без заранее согласованного сценария возврата.
2. Определите источник истины. Обычно окончательным подтверждением служит уведомление от платёжного сервиса, а не возврат пользователя в браузер. Возврат на сайт показывает, что пользователь завершил переход, но не всегда подтверждает зачисление денег.
3. Проверьте идемпотентность. Повторное уведомление о той же операции не должно создавать второй платёж, повторно отгружать заказ или ещё раз отправлять письмо клиенту.
4. Настройте возвраты и отмены. Проверьте полный и частичный возврат, отмену неоплаченного заказа и ситуацию, когда возврат начат в личном кабинете провайдера.
5. Свяжите оплату с чеком и отгрузкой. Чек, платёж и отгрузка должны ссылаться на один заказ и одинаковые суммы. Несовпадение обычно обнаруживается уже при сверке, когда исправление требует ручной работы.

Для каждого шага сохраните идентификатор операции, время, ответ сервиса и итоговый статус. Не записывайте в журналы полные данные карты, секретные ключи и токены.

Как выбрать доставку

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

Фиксированный тариф

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

Расчёт через службу доставки

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

Агрегированная доставка

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

Когда что выбирать

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

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

Собственная интеграция оправдана, когда бизнес-процесс не помещается в настройки: несколько складов, раздельные отгрузки, сложное резервирование, корпоративные договоры или требования к маршрутизации. Закладывайте не только разработку, но и поддержку после изменения API внешнего сервиса.

Что ломается чаще всего

• Статус оплаты не меняется. Проверьте доступность адреса уведомлений из интернета, HTTPS, подпись запроса и запись события в журнале. Не ориентируйтесь только на редирект пользователя.
• Уведомление приходит дважды. Обработчик должен повторно распознавать уже обработанный идентификатор операции и возвращать корректный ответ сервису.
• Доставка показывает неверную цену. Сверьте единицы веса и размеров, склад отгрузки, регион и правила округления. Проверьте тот же товар в корзине и в заказе.
• Пункт выдачи выбран, но не попал в заказ. Убедитесь, что код пункта хранится в отдельном свойстве заказа, а не только в браузере или комментарии покупателя.
• После обновления Битрикс пропала оплата. Проверьте совместимость обработчика с текущей версией PHP, модуля «Интернет-магазин» и ядра. Обновление сначала тестируют на копии сайта.

Что сделать дальше

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

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