Онлайн-оплата на 1С-Битрикс: что проверить перед подключением и после запуска

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

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

Почему оплата — это не только платёжный модуль

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

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

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

Что проверить до подключения

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

• Платёжная система. Нужно понять, какой сервис используется: банк, агрегатор, эквайринг, СБП, рассрочка, оплата по счёту или несколько способов сразу.
• Редакция и версия Битрикса. Не каждый модуль одинаково работает на старых версиях ядра, PHP и модуля интернет-магазина.
• Фискализация. Нужно заранее проверить, кто формирует чек, какие ставки НДС используются, какие данные товара передаются в кассу и как обрабатываются возвраты.
• Статусы заказа. Важно согласовать, какой статус ставится после успешной оплаты, ошибки, отмены, возврата и ручной проверки.
• Письма и уведомления. Покупатель и менеджер должны получать понятные сообщения, а не только технический ответ от платёжного шлюза.
• CRM и учётные системы. Если заказ уходит в CRM или 1С, нужно проверить, какие поля передаются после оплаты и когда именно отправляется событие.
• Тестовый режим. Нужны тестовые ключи, тестовые карты, доступ к логам и понимание, как переключиться в боевой режим.

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

Как должен проходить сценарий оплаты

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

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

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

Тестовый режим: какие заказы прогнать

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

• успешная оплата с возвратом на страницу “успешно”;
• неуспешная оплата и возврат на страницу ошибки;
• закрытие вкладки после перехода в банк, без ручного возврата на сайт;
• повторное callback-уведомление по тому же платежу;
• оплата заказа с доставкой, скидкой, промокодом или нестандартной суммой;
• заказ без обязательного email или телефона, если такие сценарии возможны;
• отмена, полный возврат и частичный возврат, если они нужны бизнесу;
• проверка письма клиенту, письма администратору и записи в CRM.

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

Статусы, повторы и возвраты

Самая частая ошибка в оплатах — считать, что “оплачено” автоматически равно “заказ можно выполнять”. Для простого сайта это может быть близко к правде, но в интернет-магазине или сервисе с интеграциями у заказа обычно есть несколько независимых состояний: создан, оплачен, подтверждён, передан в работу, отгружен, отменён, возвращён.

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

Возвраты тоже лучше проверять заранее. Важно понять, где выполняется возврат — в кабинете банка, в Битриксе, через кассу или вручную. Нужно ли менять статус заказа? Нужно ли отправлять клиенту письмо? Что должно уйти в CRM? Как фиксируется частичный возврат? Эти вопросы проще решить до запуска, чем после спорного платежа.

Чеки и фискализация

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

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

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

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

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

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

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

Когда стоит обратиться к разработчику

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

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

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

Мини-чек-лист перед боевым запуском

• есть резервная копия файлов и базы перед изменениями;
• известно, какой PHP, версия Битрикса и версия модуля используются;
• тестовые ключи заменены на боевые, а тестовый режим отключён;
• страницы успешной и неуспешной оплаты открываются без ошибок;
• callback-URL доступен снаружи и не закрыт авторизацией;
• успешная оплата меняет оплату и статус заказа ожидаемым образом;
• повторное уведомление не создаёт дублей;
• ошибка оплаты не помечает заказ как оплаченный;
• чек формируется с правильными товарами, суммами и налогами;
• письма клиенту и администратору уходят с понятным содержанием;
• CRM или учётная система получает корректный статус и сумму;
• есть план отката и человек, который сможет быстро посмотреть логи.

FAQ

Можно ли подключить оплату на Битриксе без программиста?

Иногда да, если используется штатный модуль, стандартная корзина и простой сценарий без интеграций. Но даже в этом случае стоит проверить тестовые заказы, статусы, письма и чеки. Если есть CRM, 1С, нестандартная корзина или старый сайт, лучше подключать оплату с разработчиком.

Почему деньги списались, а заказ в Битриксе не стал оплаченным?

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

Нужно ли делать тестовый контур?

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

Что делать, если не формируется чек?

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

Вывод

Онлайн-оплата на 1С-Битрикс должна проверяться как связанный процесс: заказ, платёж, callback, статус, чек, письма, CRM и действия менеджера. Если проверить только “успешно списались деньги”, можно пропустить ошибки, которые проявятся уже на реальных клиентах.

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