Платежи и доставка в Битрикс: рабочие приёмы

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

С чего начать: собрать карту заказа

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

• Редакция 1С-Битрикс: Управление сайтом 24.x с установленным модулем «Интернет-магазин».
• Доступ администратора к разделам магазина, платёжным системам и службам доставки.
• Тестовые реквизиты платёжного провайдера или тестовый режим, если его поддерживает конкретный модуль.
• Проверенные данные магазина: адрес, ИНН, расчётный счёт, контактный телефон и почта.
• Таблица зон доставки: города, регионы, пункты выдачи, курьерские тарифы, ограничения по весу и сумме.

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

Главная проверка — не «виден ли способ оплаты», а «может ли конкретный заказ пройти весь путь: корзина, оплата, подтверждение, отгрузка и уведомление».

Три рабочих подхода к подключению

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

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

Когда выбирать готовый модуль

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

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

Настройка оплаты без разрыва статусов

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

1. Создайте платёжную систему. Укажите название, описание для покупателя, валюту и доступность для нужных сайтов или организаций. Проверьте, что она привязана к нужному типу плательщика. После сохранения способ должен появиться в настройках заказа, но это ещё не подтверждает его рабочее состояние.
2. Настройте ограничения. Разделите способы по сумме заказа, региону, типу клиента и доставке. Проверьте обратную ситуацию: если способ недоступен, покупатель должен получить другой вариант, а не пустой список.
3. Разведите статусы. Статус заказа и статус оплаты — разные сущности. После возврата из платёжной формы заказ не должен автоматически переходить в «Выполнен», если отгрузка ещё не создана. Проверка: тестовый заказ получает ожидаемую отметку об оплате, а оператор видит отдельный этап доставки.
4. Проверьте уведомления. Внешний сервис должен вернуть результат не только в браузер покупателя, но и на сервер магазина. Закройте вкладку после оплаты и посмотрите, обновился ли заказ. Если статус меняется только после возврата клиента, серверное уведомление не работает или не прошло проверку.
5. Прогоните повторное уведомление. Платёжные сервисы могут отправить одно событие больше одного раза. Повтор не должен создавать вторую оплату, вторую отгрузку или повторное письмо клиенту. Проверка зависит от провайдера и его тестового режима; результат фиксируйте в журнале заказа.

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

Доставка: сначала модель, потом тариф

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

Что настроить в каждом профиле

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

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

Что ломается на практике

Способ оплаты исчезает

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

Платёж прошёл, но заказ остался неоплаченным

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

Стоимость доставки равна нулю

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

Пункт выдачи не появляется

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

Заказ получил лишнюю отгрузку

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

Что проверить перед запуском

Составьте короткий сценарий приёмки. Он должен проходить на копии сайта или в тестовом режиме, если провайдер его поддерживает.

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

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

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

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