Номер заказа, переход на платёжную страницу и подтверждённая оплата — разные события. Если сайт смешивает их в одно «Всё готово», покупатель не понимает, нужно ли ещё платить, а магазин рискует получить дубли или начать обработку неоплаченного заказа. Проверять оформление полезнее по состояниям одной покупки, чем по внешнему виду кнопки.
Разберём учебный заказ: покупатель добавляет две одинаковые синие керамические кружки, выбирает доставку по адресу и онлайн-предоплату. Ассортимент, изменения остатка и сообщения в примере вымышлены. Это сценарий проверки, а не история клиента и не правила конкретного магазина. Под отправкой ниже понимается отправка формы заказа на сервер; отгрузка товара происходит позже.
Корзина: выбранный товар ещё не стал заказом
Сначала покупатель должен сверить, что именно он собирается купить: две кружки нужного исполнения, количество, цену за единицу и стоимость товаров. Выбранный цвет и другие существенные параметры должны сохраниться при переходе из карточки товара. Общее название модели без исполнения затрудняет проверку.
Поменяйте количество, уберите товар и верните его. После каждого действия сведения в строке, общая сумма и доступность следующего шага должны согласоваться. Пока пересчёт не закончен, интерфейс должен обозначать это состояние и не выдавать прежний итог за новый. Для пустой корзины нужен понятный путь обратно к товарам, а не доступная кнопка оформления.
В нашем примере адрес пока неизвестен, поэтому стоимость доставки тоже неизвестна. Подпись «Стоимость товаров» точнее, чем «Итого к оплате». Рядом можно показать «Доставка будет рассчитана после ввода адреса». Ноль в строке доставки выглядел бы как бесплатная услуга, хотя расчёта ещё не было.
Удобное оформление начинается с достоверной корзины. Уменьшение числа полей не поможет, если человек перед нажатием кнопки не может проверить состав покупки.
Неизвестная доставка: расчёт, отсутствие услуги и сбой — разные ответы
Покупатель вводит адрес. До получения результата сайт показывает, что рассчитывает доставку. После результата — доступный способ получения, его стоимость и условия, относящиеся к этому адресу и составу корзины.
Теперь представим, что запрос расчёта завершился ошибкой. Это не означает, что доставка невозможна или бесплатна. Подходящее учебное сообщение: «Не удалось рассчитать доставку. Адрес сохранён. Повторите расчёт». Если магазин действительно предлагает другой согласованный способ получения, его можно показать рядом.
Не следует молча подставлять старый тариф после смены адреса или количества. Изменились данные заказа — нужно проверить, остаётся ли расчёт применимым. На этом шаге владелец задаёт правила: какие сведения необходимы для расчёта, что делать при недоступности сервиса и можно ли принять заказ для ручного согласования.
Если стоимость уточняет менеджер, интерфейс должен прямо объяснить, что сейчас покупатель отправляет заказ на согласование и когда узнает окончательные условия. Такой сценарий нельзя незаметно смешивать с оплатой уже рассчитанной покупки. Для нашего учебного заказа с онлайн-предоплатой сначала восстанавливаем расчёт и показываем согласованный итог. Устройство тарифов подробно разобрано в материале о расчёте доставки.
Изменение остатка: решение нужно вернуть покупателю
Пока покупатель вводил адрес, одна из кружек стала недоступна. В корзине всё ещё указано две, но оформить их на прежних условиях уже нельзя.
Сайт должен сообщить, какое предложение изменилось, и предложить доступное действие. Например: «Сейчас доступна одна синяя кружка. Измените количество или удалите товар». Покупатель выбирает одну, видит новый состав и пересчитанные условия, затем продолжает. Автоматически удалить вторую кружку и сразу списать другую сумму — плохой способ разрешить расхождение: человек не подтвердил новую покупку.
Проверка только при добавлении в корзину недостаточна. До создания заказа сервер должен заново проверить выбранное предложение и возможность продажи. Даже если две вкладки увидели последний товар одновременно, окончательная операция должна соблюдать правила остатка и резерва.
Само правило резерва нельзя угадать по дизайну. Владелец и разработчик заранее определяют, когда товар резервируется, на какой срок и как освобождается при отмене или незавершённой оплате. Корзина сама по себе не должна обещать резерв, если он не предусмотрен. Для товаров под заказ или разрешённого предзаказа нужен отдельный согласованный сценарий.
В учебном процессе мы продолжаем с одной кружкой. Контактные сведения и адрес остаются на месте; покупателю не приходится заполнять форму заново из-за изменения товара.
Отправка: ошибка поля и неизвестный результат требуют разных действий
Перед отправкой покажите состав, доставку и итоговую сумму, а также дайте исправить выбор. Кнопка должна объяснять ближайший результат: например, «Создать заказ и перейти к оплате». Она ещё не подтверждает списание денег.
Если форма содержит ошибку
Допустим, в адресе не хватает обязательного для выбранного способа доставки сведения. Сообщение должно назвать проблему и объяснить исправление рядом с соответствующим полем или в доступном списке ошибок. Красной рамки и общего «Что-то пошло не так» недостаточно.
Правильно заполненные поля сохраняют. Ошибка в адресе не должна удалять имя получателя, контакты, выбранный способ доставки и корзину. После исправления покупатель продолжает тот же процесс. Сохранение ввода здесь относится к данным оформления; оно не означает, что магазин должен сохранять введённые платёжные реквизиты.
На телефоне проверьте, видны ли ошибка и нужное поле при открытой клавиатуре. С клавиатуры компьютера должна сохраняться возможность найти поле и исправить его. Сообщение об ошибке нужно передавать текстом, доступным и для вспомогательных технологий.
Если запрос отправлен, но ответ потерялся
Покупатель нажимает кнопку, видит ожидание и нажимает снова. Затем соединение обрывается. Сайт не получил ответ, но сервер мог уже создать заказ. Поэтому таймаут нельзя автоматически переводить в «Заказ не создан, оформите заново».
На время обработки кнопку можно защитить от повторного нажатия и показать состояние «Отправляем заказ». Этого недостаточно для защиты данных: повторные запросы должны распознаваться и на сервере. Для этого используют идентификатор одной операции и идемпотентную обработку — повтор той же отправки не создаёт второй заказ.
Для владельца критерий прост: повторный клик и восстановление после потерянного ответа должны приводить к одному и тому же заказу, с тем же номером, составом и суммой. Если результат пока неизвестен, интерфейс сообщает об этом и предлагает проверить состояние или восстановить отправку. Разработчик должен обеспечить связь восстановления с исходной операцией, а не запускать новую при каждом нажатии.
Отдельно проверяют повторное создание платежа. Защита записи заказа не означает, что внешняя платёжная операция тоже защищена. У провайдеров есть собственные правила повторов и сроки действия ключей; их нужно учесть в интеграции. Изменение состава после окончательного отказа и восстановление потерянного ответа — разные действия, для которых нельзя бездумно использовать один механизм.
Ожидание оплаты: заказ уже существует, деньги ещё не подтверждены
Восстановленный ответ показывает один созданный заказ на одну кружку. Теперь покупателю доступны номер заказа, состав, итоговая сумма и действие для оплаты. Сообщение «Заказ создан. Ожидаем оплату» описывает это состояние точнее, чем «Покупка завершена».
Переход на платёжную страницу не подтверждает оплату. Возврат с неё тоже не следует считать достаточным основанием: результат нужно получить и проверить на сервере по правилам провайдера. Например, в API ЮKassa созданный платёж может ожидать действий покупателя, успешно завершиться либо быть отменён. При двухстадийной оплате предусмотрено отдельное состояние авторизованных средств до списания.
Для нашего учебного сценария выбрана обычная онлайн-предоплата. Если покупатель вернулся раньше, чем магазин получил подтверждение, ему показывают ожидание проверки результата. Если оплата отменена, сообщают именно об этом. Если связь с сервисом недоступна, не выдают неизвестный статус за отказ.
Новая попытка оплаты после подтверждённой неудачи может быть отдельной платёжной операцией, привязанной к тому же заказу. Повторять платёж при неизвестном исходе предыдущего нельзя без проверки его состояния. Состав, сумма и допустимость оплаты должны оставаться согласованными с заказом.
Для оплаты при получении правила будут другими: созданный заказ может переходить к обработке без онлайн-платежа. Это решение магазина, которое нужно явно отразить в сообщениях и статусах. Подробности выбора и настройки платёжного решения вынесены в статью о подключении оплаты на сайте.
Подтверждение: согласовать экран, запись заказа и дальнейшую обработку
Оплата учебного заказа подтверждена на сервере. Покупатель видит это состояние, а сотрудник магазина — тот же заказ с соответствующим статусом. На странице остаются номер, оплаченный состав, условия получения и понятный следующий шаг. Само подтверждение оплаты ещё не означает отгрузку.
Покупатель может закрыть вкладку сразу после оплаты и вообще не увидеть страницу результата. Поэтому изменение статуса не должно зависеть от того, загрузил ли он экран «Спасибо». Интеграция должна получать подтверждение независимо от этого перехода, например через серверное уведомление.
Уведомления тоже могут приходить повторно. Повтор подтверждения одного платежа не должен создавать ещё один заказ, повторно менять резерв или запускать дублирующую обработку. Разработчик проверяет подлинность сообщения по правилам сервиса, связь платежа с заказом и соответствие суммы; одного текста «успешно» недостаточно.
Письмо покупателю — отдельный результат. Если оно не отправилось, это не превращает подтверждённую оплату в неуспешную. У магазина должны остаться достоверная запись и возможность обнаружить сбой уведомления. Не нужно предлагать человеку заплатить снова только потому, что письмо не пришло.
Как воспроизвести проблемы до запуска
Попросите разработчика подготовить тестовую среду, управляемый остаток кружек и тестовую оплату. Нужна возможность отдельно задержать ответ создания заказа и отдельно задержать подтверждение платежа. Простое отключение интернета не доказывает, успел ли сервер выполнить операцию.
Сначала пройдите учебную покупку без сбоев и зафиксируйте её состояния. Затем проверяйте каждый случай на новом тестовом заказе с восстановленными исходными условиями. Внутри каждого случая повторные действия относятся к одной покупке.
| Что проверить | Как воспроизвести | Условие успешной проверки |
|---|---|---|
| Пустая и изменённая корзина | Изменить количество, удалить последний товар, вернуться к выбору | Состав и сумма согласованы; пустую корзину нельзя оформить |
| Неизвестная доставка | Ввести адрес, остановить ответ расчёта, затем повторить его | Не показаны бесплатная доставка или окончательный итог без основания; адрес сохранён |
| Смена условий доставки | После успешного расчёта изменить адрес или состав | Старые условия не используются как подтверждённые; новый результат виден до отправки |
| Недостаточный остаток | Положить две кружки; до отправки уменьшить доступность до одной | Понятно, что изменилось; продолжение возможно после решения покупателя; ввод сохранён |
| Ошибка поля | Оставить обязательное поле пустым, отправить форму и исправить его | Ошибка названа текстом; остальные данные и выбор сохранены |
| Повтор и потеря ответа | Отправить форму дважды; потерять ответ после создания записи; восстановить состояние | В системе один заказ, покупатель получает его исходный номер |
| Возврат до подтверждения оплаты | В тестовой интеграции задержать подтверждение и вернуться в магазин | Показано ожидание; заказ не отмечен оплаченным раньше подтверждения |
| Подтверждение без открытой страницы | Закрыть вкладку после тестовой оплаты, затем повторить её серверное уведомление | Статус обновлён независимо от вкладки; повтор не запускает дублирующую обработку |
| Неудачная оплата | Завершить тестовую оплату отказом и начать разрешённую новую попытку | Отказ отделён от ожидания; новая попытка связана с прежним заказом |
Для проверки конкуренции попросите разработчика одновременно отправить два разных тестовых заказа на последний доступный товар. Результат должен соответствовать принятому правилу продажи и резерва. Это отдельная проверка от двойного клика одного покупателя: два настоящих заказа нельзя считать одним повтором.
Для каждого случая сохраните шаги, ожидаемый результат, скриншот и фактический номер заказа, если он появился. Разработчик сверяет количество записей, связь платежей и переходы состояний по журналу. Для диагностики нужны идентификаторы и события; полные платёжные реквизиты и лишние персональные данные в журнал не включают. Результат записывают после выполнения, без заранее поставленных отметок «Пройдено».
Повторите пользовательскую часть на телефоне и компьютере, включая возврат назад, исправление ошибки и открытие существующего заказа после перезагрузки. Проверка экрана и проверка серверных записей дополняют друг друга: по одной красивой странице нельзя установить отсутствие дублей.
Что передать в работу
Если проблема уже есть, подготовьте конкретный сценарий: на каком состоянии остановилась покупка, что видел человек, появился ли заказ и что известно об оплате. Такой материал помогает определить объём доработки интернет-магазина и проверить исправление тем же способом.
При разработке нового интернет-магазина эти переходы стоит согласовать до реализации. Для каждого нужны источник достоверных данных, допустимое действие покупателя, сообщение при сбое и критерий проверки. Тогда «ошибка оформления заказа» становится конкретной задачей, а не поводом бесконечно менять форму.
Если корзину просто оставили, причина остаётся неизвестной без дополнительных данных. Но воспроизводимый сбой — потеря ввода, неверная сумма, дублирование или ложное подтверждение оплаты — уже даёт проверяемое основание для исправления.
