-
Провайдер
Подтверждение конкретного платежа
-
Уведомление
Доставка и обработка события
-
Оплата в CMS
Запись и связь с заказом
-
Процесс заказа
Статус, чек и дальнейшие действия
Если клиент сообщает об оплате, а Битрикс показывает неоплаченный заказ, не предлагайте сразу заплатить повторно. Сначала сопоставьте платёж у провайдера с конкретной оплатой в CMS. Затем проверьте доставку серверного уведомления и обработку результата. Статус заказа, факт списания и состояние чека нужно проверять раздельно.
Материал относится к интернет-магазину на «1С-Битрикс: Управление сайтом». Сценарии оплаты в Битрикс24 и сторонних конструкторах могут быть устроены иначе. Названия полей и адрес обработчика зависят от платёжного модуля, поэтому сначала зафиксируйте его название, версию и выбранную платёжную систему.
Установите, что именно произошло с деньгами
Попросите у покупателя номер заказа и время операции, но не запрашивайте полные реквизиты карты или коды подтверждения. Сотрудник с разрешённым доступом проверяет операцию в кабинете провайдера. Скриншот банковского приложения помогает найти событие, но не заменяет проверку состояния платежа на стороне получателя.
Различайте завершённый платёж и удержание суммы при двухстадийной схеме. В последнем случае может требоваться подтверждение списания. В документации ЮKassa эти состояния описываются отдельно. Не применяйте правило «банк показал операцию — отмечаем всё оплаченным» ко всем способам расчёта.
Сверьте сумму и валюту, идентификатор операции, магазин получателя и связь с заказом. Одинаковая сумма не является надёжным ключом: одновременно могут существовать несколько заказов на неё. При частичной оплате сравнивайте сумму конкретной оплаты, а не автоматически полную стоимость всей корзины.
Разложите состояние заказа на независимые части
| Уровень | Подтверждение | Чего оно не доказывает |
|---|---|---|
| Платёжный провайдер | Нужная операция имеет ожидаемое конечное состояние | CMS уже получила и применила результат |
| Оплата в Битрикс | Запись оплаты связана с этой операцией | Выполнены все действия по заказу |
| Общий статус заказа | Сработал настроенный бизнес-процесс | Деньги действительно списаны |
| Чек | Есть результат предусмотренной фискальной операции | Отгрузка разрешена или завершена |
Такое разделение предотвращает неверную постановку задачи. Если оплата отмечена корректно, а заказ не перешёл в «Сборку», проверять прежде всего нужно правила изменения статуса. Если провайдер подтвердил платёж, но запись оплаты не обновилась, внимание требуется интеграции и обработке уведомления.
В инструкции Максима Молкова по подключению платежей отдельно рассматриваются интеграция и тестирование оплаты. Для диагностики уже работающего магазина полезен обратный порядок: сначала установить фактическое событие, затем проверять настройки. Перенастройка всех параметров наугад может затронуть исправные способы оплаты.
Проверьте путь серверного уведомления
Возврат покупателя на страницу «Спасибо» и серверное уведомление — разные маршруты. Покупатель может закрыть вкладку сразу после операции. Корректное обновление должно опираться на предусмотренное интеграцией подтверждение, а не только на то, посетил ли человек страницу успешной оплаты.
ЮKassa описывает события уведомлений, проверку их подлинности и ответ HTTP 200 при успешном приёме. Передайте разработчику время события и идентификатор платежа: по ним можно сопоставить попытку доставки с журналом сервера. Самостоятельно открытая страница обработчика в браузере не воспроизводит настоящий запрос провайдера.
Проверьте, не изменился ли домен, HTTPS, маршрут обработчика или правило защиты после переноса сайта. Возможны недоступность адреса, перенаправление, требование авторизации и серверная ошибка. Важен ответ на реальный запрос нужного типа. Наличие рабочего главного экрана сайта не подтверждает исправность этого маршрута.
Не отключайте защиту сайта целиком ради проверки. Настройки доступа согласуют точечно по документации модуля и провайдера. Не публикуйте секретный ключ в задаче или переписке. Диагностические журналы должны храниться с ограниченным доступом и без избыточных платёжных данных.
Найдите расхождение внутри CMS
Если уведомление дошло, проверьте, какой заказ и какую оплату нашёл обработчик. Ошибки сопоставления особенно важно исключить при нескольких сайтах, миграции данных и частичных платежах. Зафиксируйте фактические идентификаторы с обеих сторон; не заменяйте их совпадением номера, который покупатель видит в письме.
Посмотрите журнал модуля и ошибки приложения в тот же момент. Проверяйте только относящийся к событию интервал, чтобы не утонуть в старых записях. Если обновление прервано ошибкой, выясните, на каком действии: разбор сообщения, поиск оплаты, сохранение или последующий пользовательский обработчик.
В документации модуля Slytek описаны отдельные настройки схемы платежа и последующих операций. Это показывает, почему инструкция одного модуля не подходит всем интеграциям. Проверьте именно установленное решение. Не переносите адреса, галочки и обработчики из чужого примера без сопоставления с вашей конфигурацией.
Подготовьте задачу, которую можно воспроизвести
Передайте исполнителю номер заказа, идентификатор оплаты CMS, идентификатор провайдера, точное время с часовым поясом, сумму и ожидаемый результат. Приложите обезличенный фрагмент ошибки и сведения об изменениях перед сбоем. Укажите, проблема затрагивает одну операцию или повторяется на определённом способе оплаты.
Условный пример: операция подтверждена провайдером, уведомление получило серверную ошибку, в CMS сохранилось прежнее состояние. Здесь задача — восстановить корректную обработку и согласовать повторное применение уже существующего результата. Создание нового платежа не исправляет исходное расхождение и может привести к двойной оплате.
Ручную коррекцию состояния выполняет уполномоченный сотрудник по подтверждённым данным и регламенту. Сохраните, кто, когда и на каком основании изменил запись. Не используйте массовое проставление признака оплаты как способ «убрать красные заказы»: оно скрывает нерешённую причину и усложняет сверку.
Примите исправление на нескольких сценариях
Проверяйте доработку в тестовом режиме, предусмотренном провайдером, отдельно от реальных покупателей. Нужны успешная операция, отмена, закрытие вкладки без возврата и повторная доставка одного события. Последний сценарий важен: повтор не должен повторно списывать деньги или запускать повторную отгрузку.
Если магазин поддерживает частичную оплату, включите её в протокол. Если используется двухстадийная схема, отдельно проверьте ожидание и подтверждение. Фиксируйте результат на каждом уровне таблицы, а не ограничивайтесь зелёной надписью в интерфейсе. Порядок общего контроля есть в плане проверки запуска магазина.
Для дальнейшей эксплуатации определите, кто замечает расхождения и выполняет сверку. Включите проверку оплат в состав поддержки Битрикс. Если же посетитель вообще не доходит до платёжного сервиса, нужен другой разбор — диагностика оформления заказа.
Вопросы об оплате и статусах
Можно попросить покупателя оплатить ещё раз?
Не до проверки первой операции. Сначала выясните её состояние у провайдера и связь с заказом. При неопределённом результате согласуйте дальнейшие действия с поддержкой платёжного сервиса, чтобы исключить повторное списание.
Почему чек есть, а заказ всё ещё новый?
Фискальная операция и рабочая стадия заказа не обязаны изменяться одним действием. Сопоставьте платёж, запись оплаты и настроенный переход статуса. Конкретный состав чеков проверяйте по вашей схеме расчётов, а не по названию стадии.
Что делать с секретными ключами при передаче задачи?
Не прикладывайте их к открытому тикету. Организуйте ограниченный доступ через принятый в компании защищённый канал. Для первичной диагностики обычно нужны идентификаторы события, настройки без секретов и относящийся к нему журнал.
