Почему в корзину возвращались удалённые товары: доработки Primula

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

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

Какая последовательность обнаружила ошибку

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

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

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

Почему исправляли источник данных корзины

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

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

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

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

В проверенной конфигурации магазина оплата частями была доступна от 5 000 ₽. Два платка давали сумму 5 800 ₽, один платок стоил 2 900 ₽. Этого сценария хватало, чтобы пройти через границу доступности способа оплаты.

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

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

На проверочном экране с одним платком итог составляет 2 900 ₽. Способы с минимальной суммой 5 000 ₽ недоступны, выбран вариант «Банковская карта». Это состояние после уменьшения количества, а не просто страница, открытая сразу с маленькой корзиной.

Какие состояния важно согласовать в оформлении

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

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

Что подтвердили на рабочем сайте

После выпуска мы повторили уменьшение количества, удаление товара и переходы через ранее посещённые страницы. Корзина сохраняла актуальное количество, удалённые позиции не восстанавливались. При снижении суммы с 5 800 до 2 900 ₽ недоступная оплата частями сбрасывалась на карту.

Для всего выпуска исправлений прошли 103 теста интерфейсной логики, 13 проверок до переключения и 17 проверок на публичном сайте. В эти числа входили и другие доработки оформления, поэтому считать их отдельным покрытием только корзины было бы неверно.

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

Где заканчивается проверка интерфейса

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

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

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

Как заметить проблему до обращения покупателя

Для короткой ручной проверки возьмите недорогой товар, положите две единицы и начните оформление. Измените количество, вернитесь в корзину и снова продолжите заказ. Затем повторите путь с удалением товара и, если у магазина есть ограничения по сумме, с изменением доступности оплаты.

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

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

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