ТЗ на оформление заказа: итоговая сумма, оплата и повторы

Опишите заказ как последовательность состояний

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

Разделите состояние заказа и состояние платежа. Заказ может ожидать оплаты, а успешный платёж — ещё требовать сверки с системой магазина. Отдельно определите, какое событие разрешает сборку или выдачу товара. Названия и переходы должны одинаково пониматься разработчиком, оператором и бухгалтерской системой.

Определите источник итоговой суммы

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

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

Промокоды и бонусы требуют правил совместимости, округления и отмены. Проверьте пограничные суммы и минимальные условия. Фраза «скидка работает» не заменяет контрольного расчёта с заранее известным результатом.

Согласуйте поля и способы получения

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

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

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

Защитите одну операцию от повторов

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

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

Разделите повтор неизменённой операции и новый заказ после редактирования корзины. Если ключ применяется слишком широко, система может ошибочно вернуть старый результат вместо новой покупки. В ТЗ укажите состав операции, срок жизни ключа и поведение при изменившихся параметрах.

Подтверждайте платёж доверенным событием

Возврат браузера на страницу успеха не является достаточным подтверждением оплаты. Опишите проверку уведомления провайдера, привязку к заказу, сверку суммы и допустимые переходы. Общие принципы обработки webhook-событий описаны в документации Stripe; конкретный формат зависит от выбранной интеграции.

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

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

Опишите восстановление и отмену

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

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

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

Проверьте матрицу отказов

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

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

Соберите требования для оценки

В скачиваемый бриф внесите источники условий, таблицу состояний, поля, правила повторов и сценарии восстановления. Отдельно перечислите зависимости от провайдера, доставки и учётной системы. Неподтверждённые возможности нужно проверить до фиксации срока внедрения.

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