Описать проблему ↗

Дубли и данные

Битрикс создаёт повторный заказ после обновления страницы

После обновления страницы Битрикс создаёт ещё один заказ. Объясняем, как проверить повторную отправку формы и защитить оформление на сервере.

Редакция «починимсайт» · Обновлено · 3 мин. чтения

Что происходит и с чего начать

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

Что можно проверить самостоятельно

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

Как понять результаты проверки

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

Что проверяет разработчик

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

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

На что обратить внимание

Если после обработки POST браузеру возвращается страница без перехода, обновление может повторить отправку. Однако переход после POST сам по себе не защищает от параллельных запросов.

Как исправляют причину

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

Как убедиться, что проблема решена

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

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