Интернет-магазины / Блог ontech.pro
Как предотвратить повторное создание одного заказа
Покупатель нажал кнопку ещё раз, потому что экран не изменился. В результате менеджер получил две одинаковые покупки. Причина может быть в интерфейсе, сервере или обмене с CRM, поэтому защита должна охватывать весь путь операции.
Подготовила команда ontech.pro · · 3 мин чтенияОпределите, что считается повтором
Одинаковые товары и телефон не доказывают ошибку: человек действительно может сделать две покупки подряд. Нужен признак одной попытки оформления, который сохраняется при повторной отправке из-за задержки. Это отдельное техническое требование, а не поиск похожих заказов задним числом.
Опишите примеры: двойное нажатие в одной форме, обновление страницы, возврат после оплаты и новый заказ на следующий день. Для первых случаев обычно требуется вернуть существующий результат, для последнего — разрешить новую покупку. Критерий должен быть согласован до выбора реализации.
Покажите, что действие принято
После отправки кнопка и экран должны сообщать о процессе. При ожидании человек не должен гадать, сработало ли нажатие. Если ответ задерживается, сохраните состав и предложите проверку результата. Простая блокировка кнопки полезна для удобства, но не покрывает повторный сетевой запрос или открытие другой вкладки.
После создания покажите номер заказа и доступ к нему. Возврат к форме не должен автоматически означать новый заказ. Разработчику стоит передать требование восстановить уже созданный результат, когда система достоверно связывает страницу с завершённой попыткой.
Отдельно защитите платёжную операцию
Провайдеры используют собственные правила повторных запросов. Например, ЮKassa поддерживает ключ идемпотентности: повтор с тем же ключом и данными позволяет получить результат исходной операции в пределах описанных сервисом условий. Это защита конкретного обращения к API, а не автоматическое объединение всех заказов магазина.
Поэтому разработчик должен связать внутреннюю попытку оформления, заказ и платёж. Новый ключ при каждом повторе может означать новую операцию. Сроки и ограничения механизма проверяют в актуальной документации выбранного сервиса и учитывают отдельно от поведения кнопки.
Документация: ЮKassa: идемпотентность запросов
Сохраните правило при обмене
Если сайт передал заказ в CRM и не получил ответ, повторная отправка должна находить ту же покупку по внешнему идентификатору. Иначе витрина останется правильной, а менеджеры всё равно увидят дубли. Аналогичное требование полезно для учётной системы и уведомлений.
Не полагайтесь только на ручное удаление повторов. Сотруднику нужен журнал попыток и понятный статус передачи. При подозрении на дубль нельзя автоматически отменять оплату или удалять данные: сначала требуется установить связь и применить согласованный порядок исправления.
Проверьте сбои намеренно
На тестовом окружении повторите запрос, задержите ответ, откройте две вкладки и вернитесь после успешной оплаты. Затем проверьте число заказов, платежей, резервов и сообщений. Один визуальный номер на экране ещё не доказывает, что в связанных системах создана одна запись.
Добавьте отдельный сценарий законной повторной покупки с тем же составом. Защита не должна блокировать постоянного клиента. Результат приёмки — предсказуемое различение повторной доставки одной операции и новой покупки, с возможностью объяснить решение по сохранённой истории.