Аудит оформления заказа: как проверить доставку, форму и оплату

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

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

1. Подготовьте условия и границы проверки

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

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

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

2. Пройдите основной маршрут и сверяйте итог

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

Условный пример расчёта. Два товара по 3 000 ₽ дают 6 000 ₽. При скидке 10% только на товары и доставке 350 ₽ итог равен 6 000 − 600 + 350 = 5 750 ₽. Если выбранный пункт выдачи стоит 200 ₽, новый итог — 5 600 ₽. Это проверочные числа, не тариф и не результат реального магазина. Правила округления и совместимости скидок берите из условий своего проекта.

3. Используйте сценарии с проверяемым результатом

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

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

4. Проверяйте исправление ошибки, а не только её появление

Найдите ошибку в форме глазами покупателя: понятно ли, где остановка и что изменить? Затем исправьте значение и продолжите покупку. Зафиксируйте, исчезло ли сообщение, не потерялся ли выбор доставки и можно ли перейти дальше с клавиатуры телефона.

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

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

5. Разделяйте заказ, платёж и экран подтверждения

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

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

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

6. Сверьте события с действительными действиями

Согласуйте, в какой момент фиксируется начало оформления, выбор доставки, передача способа оплаты и покупка. В официальной схеме GA4 для этих действий предусмотрены разные события. Их названия не универсальны для всех систем. Сначала запишите определения событий своей интеграции, затем проверьте время отправки, состав заказа и идентификатор транзакции.

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

7. Передайте проблему так, чтобы её можно было повторить

Запись «неудобная доставка» оставляет команде слишком много догадок. Полезнее: «В тестовом сеансе на таком-то телефоне после смены курьера на ПВЗ итог остался прежним; приложены шаги, выбранный пункт и два экрана. Ожидается пересчёт до подтверждения заказа». Это пример формулировки задачи, не находка на конкретном сайте.

• Дефект: ожидаемое поведение согласовано, расхождение воспроизведено и сохранено доказательство.
• Гипотеза: интерфейс работает по правилам, но есть предположение о затруднении пользователя; нужна дополнительная проверка.
• Непроверенный участок: нет доступа или тестовых условий. Не ставьте ему статус «ошибок нет».

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

8. Закройте задачу повторной проверкой

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

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