Как не создать два заказа после сбоя связи?

Ответ пропал, а заказ мог сохраниться

У отправки есть два пути: просьба уходит с телефона в магазин, подтверждение возвращается обратно. Связь может оборваться на обратном пути, когда магазин уже записал заказ. Тогда клиент видит ожидание или ошибку, а команда видит готовую запись.

Возьмём учебный пример. В демонстрационном магазине создан заказ №104 на 6 000 ₽. Тестовая оплата завершена, сотруднику поставлено поручение «собрать заказ». Ответ для покупателя не дошёл. Номер, сумма и поручение здесь условные; это ситуация для проверки, а не история клиента.

Кнопка «Попробовать ещё раз» выглядит разумно. Но если она запускает всё заново, вместо потерянного подтверждения магазин получает №105, вторую оплату и ещё одно поручение. У сотрудника нет причины догадаться, что один из двух заказов лишний.

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

Закрытие страницы тоже не сообщает магазину: «я передумал, отмените покупку». Уже начатая работа может продолжиться. Остановить ожидание на телефоне и отменить сохранённый заказ нужно проверять отдельно.

Как избежать повторного заказа при нажатии кнопки

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

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

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

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

Теперь клиент получил №104 и сознательно заказывает ещё такой же комплект. Товар, сумма и адрес могут полностью совпасть. Это новая покупка: у неё своя запись и свои действия. Запрет по совпадению телефона и суммы способен остановить вполне нужный заказ.

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

Отмена меняет уже созданный заказ и имеет собственный результат. Её нельзя вывести из закрытой вкладки или второй отправки. Подробный путь выхода разобран в статье об отмене записи и заказа; здесь достаточно не смешать три намерения.

Проверьте заказ, оплату и поручение вместе

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

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

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

Платёжный сервис может защищать свои операции от повторов. Например, ЮKassa возвращает исходный результат при повторной отправке тех же данных с той же служебной меткой. Это правило действует 24 часа после первой отправки. Другую метку сервис принимает за новую операцию, а после указанного срока его защита уже не позволяет рассчитывать на прежнее поведение.

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

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

Кто проверит неизвестный результат

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

Для нашего примера он может выглядеть так: «Заказ №104 сохранён. Результат оплаты пока проверяем. Повторно платить не нужно». Рядом нужен доступный способ открыть состояние заказа или обратиться за проверкой. Такое сообщение допустимо, если заказ действительно найден и команда умеет проверить результат оплаты.

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

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

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

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

Проведите три проверки на демонстрации

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

Для примера возьмём товар на 6 000 ₽ с немедленной тестовой оплатой и одной задачей «собрать заказ». Перед каждой из трёх проверок используйте новый набор тестовых записей. Номер №104 служит обозначением первой покупки; реальный номер на вашей демонстрации может отличаться.

Двойное нажатие

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

Потерянное подтверждение

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

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

Отдельная вторая покупка

Получите результат №104, затем явно оформите новый заказ с тем же товаром и суммой. Ожидаем отдельный №105. Если обе тестовые покупки успешно оплачены, в этом опыте будут два заказа, два платежа и две задачи, каждая по своему заказу. Защита должна сохранить вторую покупку, которую человек действительно хотел сделать.

Заполните лист для этих трёх проверок: действие клиента, найденный заказ, результат тестовой оплаты, задача, сообщение на экране и ответственный за неясный случай. Готовая учебная строка: «Подтверждение потеряно; повтор отправлен; №104, 6 000 ₽; один успешный тестовый платёж; одна задача; показан прежний заказ». Дежурный менеджер в примере отвечает за случаи с неизвестным результатом. В своём листе вместо ожидаемых значений запишите то, что увидели.

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

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

Примите поведение после сбоя

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

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