Интернет-магазины
Сайты
Дизайн
Поддержка
Продвижение
ИнтеграцииПокупатель дошёл до корзины, но не оформил заказ: что проверить
Добавление товара в корзину ещё не означает готовность купить. Посетитель может сравнивать предложения, не подходить под условия доставки или столкнуться с ошибкой. Чтобы разобраться, нужно отдельно проверить удобство оформления, создание заказа и подтверждение оплаты. Ниже — маршрут проверки, заполненный учебный пример и сценарии, которые можно передать разработчику.
1. Разделите оформление на проверяемые этапы
Начните не с изменения цвета кнопки, а с ответа: что именно магазин считает завершением оформления? Созданный в базе заказ, переход в платёжную систему и подтверждённое списание — разные события. При оплате при получении успешный заказ вообще не обязан иметь онлайн-платёж.
Учебный маршрут ниже относится к магазину с доставкой и онлайн-оплатой. При самовывозе меняется второй шаг, но номер заказа должен связывать сайт, платёжную операцию и работу менеджера. Покупатель может закрыть вкладку после оплаты: результат не должен зависеть только от возвращения на страницу благодарности.
- КорзинаТовар, вариант, количество и актуальная цена
- Доставка и контактДоступный способ, стоимость и адрес
- Заказ сохранёнНомер заказа и итоговая сумма на сервере
- Оплата подтвержденаСервер проверил статус операции у провайдера
- ОбработкаМенеджер видит заказ, оплату и следующий шаг
Каждый переход проверяется отдельно; онлайн-оплата не равна созданию заказа.
2. Найдите место потери, а не обвиняйте всю корзину
Сопоставляйте последовательные этапы одной воронки, одинаковый период и одинаковую единицу подсчёта. В учебной таблице ниже считаются уникальные тестовые сессии, последовательно прошедшие шаги; каждый этап вложен в предыдущий. В этой упрощённой модели одна сессия создаёт не больше одного заказа: поэтому на последних двух шагах число сессий равно числу соответствующих заказов. Это вымышленные данные, не результаты ActiveLab и не отраслевые нормативы.
| Этап | Сессии | Что видим | Следующая проверка |
|---|---|---|---|
| Открыли корзину | 200 | Исходная группа | Проверить состав и стоимость до оформления |
| Начали оформление | 120 | 80 не перешли дальше | Видна ли доставка; не требует ли сайт регистрации |
| Выбрали доставку | 90 | 30 остановились на адресе | Проверить населённые пункты и расчёт тарифа |
| Создали заказ | 72 | 18 не завершили форму | Ошибки полей, промокоды и сохранение данных |
| Подтвердили онлайн-оплату | 54 | 18 созданных заказов ещё не оплачены | Разделить ожидание, отказ, другой способ оплаты и сбой статуса |
Если таблица не помещается на экране, прокрутите её по горизонтали.
До заказа дошли 72 / 200 × 100 = 36% сессий исходной группы. Но оставшиеся 128 сессий нельзя объявить потерянными продажами: у посетителей могли быть другие намерения. Последние 18 заказов проверяют по статусам и времени ожидания, а не автоматически записывают в технические ошибки.
На реальном сайте сначала убедитесь, что измерение корректно: событие не должно отправляться при каждом обновлении страницы. Отсутствие события в аналитике также не доказывает отсутствия заказа — сравните идентификаторы с базой магазина.
3. Сделайте сумму, доставку и обязательные поля понятными
Покупателю нужно до подтверждения видеть, что он получает и сколько заплатит. Если тариф зависит от адреса, объясните это рядом со стоимостью, а после расчёта обновите итог. Не называйте неизвестную доставку бесплатной. При смене способа доставки заново проверьте адрес, доступность оплаты и сумму.
Полезная форма просит только сведения, необходимые для выбранного сценария. Для самовывоза не нужен адрес курьерской доставки. По возможности разрешите оформление без обязательного создания аккаунта. Подписи полей должны оставаться видимыми, автозаполнение — работать, а ошибка — объяснять способ исправления, не только окрашивать рамку.
Например, вместо «Неверные данные» напишите: «Укажите номер телефона с кодом страны». Уже заполненные поля при этом сохраняются. После ошибки фокус перемещается к проблемному полю, а уведомление доступно пользователям экранных дикторов. Проверять нужно настоящую форму на телефоне, а не только картинку макета.
Документация: web.dev: формы адреса и оплаты; W3C WAI: понятные уведомления об ошибках формы;
4. Проведите 12 сценариев проверки оформления
Это готовые постановки тестов, а не отчёт об уже проведённой проверке. Выполняйте их на тестовой копии с тестовыми платёжными средствами провайдера. Для каждого сценария запишите устройство, браузер, время, номер заказа и фактический результат. Условные цены и тарифы замените правилами своего магазина.
| Сценарий | Действие и данные | Ожидаемый результат | Доказательство |
|---|---|---|---|
| 01. Обычный заказ | Товар 100 BYN, 2 шт., доставка 10 BYN | Заказ на 210 BYN; состав и сумма совпадают на всех шагах | Номер заказа и снимок состава в админке |
| 02. Последняя единица | Две тестовые сессии пытаются купить последний товар | Соблюдается правило резерва; нет двух обещаний наличия одной единицы | Журнал резерва и ответы обеим сессиям |
| 03. Цена изменилась | Изменить цену после добавления товара в корзину | Перед подтверждением показана новая сумма и запрошено согласие | Старое и новое значение, состав заказа |
| 04. Недоступная доставка | Выбрать населённый пункт вне зоны курьера | Доступна подходящая альтернатива либо ясное сообщение; нет ложного тарифа | Адрес, ответ расчёта и текст покупателю |
| 05. Смена способа | Курьер → самовывоз → курьер | Пересчитан итог; адрес нужен только там, где используется | Снимки трёх состояний и итог заказа |
| 06. Ошибка контакта | Оставить обязательный телефон пустым | Заказ не отправлен; ошибка понятна; остальные данные сохранены | Запись экрана и отсутствие нового заказа |
| Сценарий | Действие и данные | Ожидаемый результат | Доказательство |
|---|---|---|---|
| 07. Двойное нажатие | Дважды отправить одну попытку заказа при медленном ответе | Одна логическая операция создаёт один заказ; повтор узнаётся сервером | Идентификатор попытки и один заказ |
| 08. Отказ оплаты | Использовать предусмотренный провайдером тестовый отказ | Заказ не помечен оплаченным; понятен безопасный следующий шаг | Статус операции и статус заказа |
| 09. Закрытая вкладка | Закрыть страницу после тестового успешного платежа | Сервер получает подтверждение; статус обновлён без возврата браузера | Сопоставление операции и заказа |
| 10. Повтор уведомления | Повторить одно подписанное тестовое уведомление провайдера | Оплата и обработка не задваиваются | Идентификатор события и журнал обработки |
| 11. Неясный ответ | Смоделировать тайм-аут при запросе оплаты | Сначала проверяется статус; покупателя не подталкивают платить вслепую ещё раз | Журнал проверки статуса и сообщение покупателю |
| 12. Промокод и возврат назад | Применить условную скидку 10%, вернуться и изменить количество | Скидка пересчитана по правилам; итог совпадает с серверным заказом | Корзина до и после, расчёт скидки |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Если в магазине нет онлайн-оплаты, замените сценарии 08–11 проверкой счёта, оплаты при получении и подтверждения менеджером. Не проводите тесты отказов или повторов на реальных покупателях. Снимки и журналы передавайте без карточных данных, паролей и лишних персональных сведений.
5. Не путайте защиту кнопки с защитой заказа
Временно отключённая кнопка уменьшает случайные повторы, но сама по себе не защищает от повторной отправки запроса. На сервере нужна проверка идентификатора логической операции. Сумму, скидку и доступность товара сервер также проверяет самостоятельно, а не принимает на доверии из браузера.
Платёжное уведомление может прийти повторно или не в ожидаемом порядке. В документации Stripe эти особенности описаны явно: обработчик должен проверять подлинность события и учитывать уже обработанные идентификаторы. Это пример принципа интеграции, не рекомендация платёжного сервиса для Беларуси. Конкретные статусы, подписи и порядок повторов берут из документации подключённого магазином провайдера.
Неопределённый ответ — отдельное состояние. Если запрос завершился тайм-аутом, платёж мог успеть пройти. Правильное действие — выяснить его статус по сохранённому идентификатору. Сообщение «Проверяем оплату заказа №…» честнее, чем неподтверждённое «Ошибка, оплатите снова».
Документация: Stripe: повторные уведомления и проверка подлинности событий; Stripe API: идемпотентные запросы;
6. Принимайте исправление по повторному тесту
Задача «исправить корзину» слишком широка. Хорошая запись содержит условия воспроизведения, ожидаемое поведение, изменение и способ повторной проверки. Ниже заполнен учебный пример постановки; поле фактического результата намеренно не выдаёт план за выполненный тест.
| Поле | Заполненный пример |
|---|---|
| Дефект | После перехода с курьера на самовывоз в итоге остаётся 10 BYN доставки |
| Условия | Тестовый товар 100 BYN; курьер 10 BYN; самовывоз 0 BYN |
| Ожидаемый итог | 100 BYN после выбора самовывоза и в сохранённом заказе |
| Задача разработчику | Пересчитывать итог на сервере при смене доставки; обновлять показанную сумму |
| Повторная проверка | Сценарий 05 на компьютере и телефоне, затем обычный заказ 01 |
| Статус образца | Тест не выполнен: после проверки приложить номер заказа, дату и фактическую сумму |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Сначала устраняют подтверждённые ошибки денег, сохранения и статусов. Затем проверяют неудобства формы и доставки. После публикации исправлений сравнивают сопоставимые периоды и устройства, учитывая изменения рекламы, цен и ассортимента. Рост конверсии нельзя обещать только на основании прохождения тестов: техническая работоспособность — необходимое условие, но не доказательство спроса.
Частые вопросы
Нужно ли сразу сокращать оформление до одной страницы?
Нет. Сначала проверьте конкретные затруднения. Короткая форма с непонятными условиями хуже нескольких ясных шагов. Сравнивайте завершение сценария и число ошибок, а не только количество экранов.
Почему заказ есть, а аналитика не показывает покупку?
Событие могло не отправиться, быть заблокировано или иметь неверный идентификатор. Проверьте заказ в базе, настройку события и одинаковый период. Аналитика не заменяет реестр заказов и подтверждения платежей.
Можно ли проверять онлайн-оплату обычной картой?
Для отказов, повторов и нестандартных случаев используйте тестовый режим провайдера. Проверка реального платежа после настройки — отдельный согласованный сценарий с контролем суммы, уведомлений и возврата, если он предусмотрен.
Что передать специалисту для начала проверки?
Адрес страницы, проблемный сценарий, устройство и браузер, время ошибки и обезличенный номер заказа. Полезны правила доставки, скидок и резерва. Не отправляйте карточные данные или пароли в переписке.
Источники и документация
Материал подготовлен для владельцев бизнеса на основе официальной документации. Примеры и планы работ в тексте — учебные: состав решений зависит от конкретного сайта.
Если нужна помощь с описанной задачей, посмотрите состав услуги Разработка и развитие интернет-магазина. Объём работ, сроки и стоимость согласуются после изучения вашего проекта.
