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

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

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

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

Выберите способ проверки

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

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

Чек-лист платёжной системы

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

Оплата — не одна кнопка, а цепочка подтверждений. Если заказ и операция расходятся по номеру, сумме или статусу, покупатель может заплатить, а магазин — не заметить этого вовремя.

Чек-лист доставки и сквозного заказа

1. Проверьте зоны и ограничения. Оформите заказ по адресу внутри зоны доставки и за её пределами. Проверьте минимальную сумму, габариты и доступные способы получения, если эти ограничения использует ваша служба. Результат: сайт предлагает только допустимые варианты и показывает согласованную стоимость.
2. Сверьте состав заказа. Создайте заказ с несколькими товарами, разным количеством и скидкой. Сравните состав, вес или габариты, объявленную ценность и итоговую сумму в Битрикс и кабинете доставки. Результат: служба получает те данные, по которым сайт рассчитал доставку.
3. Проверьте адрес и контакты. Используйте тестовый адрес с корпусом или квартирой и корректный тестовый номер телефона. Убедитесь, что данные не теряются при передаче и соответствуют формату, который принимает служба. Результат: тестовый заказ появляется в кабинете доставки без ручного исправления полей.
4. Проведите полный сценарий. Оформите заказ, оплатите его тестовым способом, передайте в доставку и обновите статус доступным штатным способом интеграции. Результат: статус оплаты, статус доставки и данные заказа согласованы в системах.
5. Проверьте отмену и повторную передачу. Отмените тестовый заказ и проверьте, не остаётся ли активная доставка. Затем повторите передачу, если интеграция допускает такую операцию. Результат: нет двух отправлений на один заказ и отменённая доставка не выглядит активной.

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

Что ломается на стыках

Чаще всего сбой не выглядит как полная недоступность. Проверьте эти случаи до переключения на боевые реквизиты:

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

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

Когда переходить в продакшен

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

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

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

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

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