Ошибка: промокод ломает оформление заказа (разбор кейса интеграции с Mindbox)

Содержание

1. Контекст: как промокод заблокировал оформление заказа
2. Диагностика: от логов к первопричине
3. Решение: как мы исправили логику скидок
4. Инсайты
5. Рекомендации
6. Ошибки, которых стоит избегать

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

Контекст: как промокод заблокировал оформление заказа

В интернет-магазине, где уже была настроена интеграция с Mindbox, возникла странная проблема. При выборе определённого варианта курьерской доставки и попытке оформить заказ пользователь видел невнятную ошибку. Никакой конкретики: ни «скидка не применилась», ни «промокод недействителен» — просто отказ системы завершить оформление.

На первый взгляд проблема выглядела как баг чекаута — ошибка на стороне интерфейса или сбой при передаче данных о доставке. Но после анализа логов запросов к Mindbox выяснилось: источник сбоя — акция promo-12345. Размер скидки, переданный из внешней системы, превышал стоимость товарной позиции. Это нарушало ограничение API: «Запрещено передавать размер внешней скидки больше чем цена линий». В результате Mindbox отказывался обрабатывать корзину, и процесс оформления прерывался.

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

Диагностика: от логов к первопричине

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

Логи сразу показали: для акции promo-12345 Mindbox возвращает отказ. Текст ошибки указывал на нарушение ограничения: «Запрещено передавать размер внешней скидки больше чем цена линий». Это означало, что сумма скидки на конкретную товарную позицию превышает её стоимость. Например, скидка 500 рублей на товар ценой 300 рублей — Mindbox считает такую ситуацию некорректной и прерывает расчёт.

Ограничение Mindbox: «Запрещено передавать размер внешней скидки больше чем цена линий»

Мы разобрались в сути ограничения. Mindbox не позволяет, чтобы размер внешней скидки на строку корзины превышал её цену. Это логично: иначе итоговая сумма по позиции стала бы отрицательной, что нарушает экономику заказа. Однако в нашем проекте валидация этого условия была реализована только на стороне административной панели при создании акции. Сама внешняя акция, приходящая от Mindbox, не проверялась на непревышение цены товара перед передачей в запрос. То есть бэкенд отправлял скидку «как есть», без дополнительной проверки границ.

Таким образом, первопричина — отсутствие серверной валидации на этапе формирования запроса к Mindbox. Акция promo-12345 была настроена с фиксированной скидкой, которая в некоторых сценариях (из-за комбинации с другими скидками или типом доставки) оказывалась выше цены товара. Ни фронт, ни бэкенд не отсекали этот случай, и Mindbox последовательно блокировал всю корзину.

Решение: как мы исправили логику скидок

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

Первое — добавили на бэкенде проверку: перед отправкой запроса в Mindbox размер скидки на каждую товарную позицию сравнивается с её ценой. Если скидка превышает цену, она автоматически обрезается до стоимости товара. Это гарантирует, что Mindbox никогда не получит некорректное значение, и расчёт корзины не прервётся. После внедрения этой проверки ошибка перестала воспроизводиться.

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

Синхронизация скидочных плашек и фактической цены

Проблема с плашками была не менее важной, чем сама ошибка в чекауте. Если пользователь видит на карточке товара «Скидка 50%», а при попытке оформить заказ получает ошибку, доверие к магазину падает. Мы привели визуальное оформление в соответствие с реальной логикой: теперь плашка отображается только для тех акций, которые гарантированно пройдут валидацию на стороне Mindbox. Это не решило техническую проблему, но устранило источник ложных ожиданий у покупателей.

Инсайты

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

• Внешние скидки требуют бэкенд-валидации. Полагаться только на фронтовые проверки — рискованно. Ограничение API Mindbox — не баг, а защитный механизм, который должен дублироваться на стороне сервера.
• Логирование запросов к API — ключ к быстрой диагностике. Без него ошибка могла бы неделями маскироваться под баг чекаута. Логи позволяют увидеть точное тело запроса и ответа, а не гадать по косвенным симптомам.
• Лимиты скидок нужно синхронизировать между CMS и движком корзины. Если в админке акция настроена на 50%, а в расчёте участвует фиксированная сумма, которая может превысить цену товара — рано или поздно возникнет коллизия.
• Один некорректный промокод может заблокировать целый способ доставки. Пользователь видит не «ошибку скидки», а отказ оформить заказ. Это прямой путь к потере конверсии и доверия.

Рекомендации

Опираясь на этот опыт, сформулируем четыре практические рекомендации для проектов, интегрированных с Mindbox или аналогичными системами лояльности.

• Добавьте на бэкенде проверку: размер скидки не должен превышать сумму цен товарных позиций.
  Это самая надёжная защита от ошибки «Запрещено передавать размер внешней скидки больше чем цена линий». Проверку нужно выполнять перед отправкой запроса в Mindbox, а не полагаться на то, что фронт или админка уже всё отсекли.
• Логируйте тело запросов и ответов при расчёте корзины.
  В нашем случае именно логи позволили за минуты найти проблемную акцию и понять причину отказа. Без логов диагностика могла бы занять дни, а ошибка так и осталась бы невидимой для разработчиков.
• При интеграции с Mindbox передавайте contactKey и точки контакта.
  Эти параметры позволяют отследить цепочку расчётов и связать конкретную сессию пользователя с действиями системы лояльности. Это упрощает анализ инцидентов и помогает воспроизводить сценарии на стейдже.
• Тестируйте критические сценарии чекаута на стейдже с реальными промокодами перед релизом.
  Граничные случаи — промокод с фиксированной скидкой на дешёвый товар, комбинация нескольких акций — должны проверяться в окружении, максимально близком к боевому. Это единственный способ убедиться, что валидация работает корректно.

Ошибки, которых стоит избегать

Выделим три антипаттерна, которые чаще всего приводят к сбоям в расчёте скидок.

• Игнорирование предупреждений API внешних систем.
  Если Mindbox возвращает ошибку или предупреждение — не пропускайте его. Даже если заказ формально создаётся, расчёт может быть некорректным, и последствия проявятся позже (например, в отчётах или при возвратах).
• Валидация скидок только на фронте.
  Пользовательский интерфейс — ненадёжная граница. Ограничения, работающие в браузере, легко обходятся или не срабатывают в нестандартных сценариях. Все проверки должны дублироваться на серверной стороне.
• Смешивание разных типов скидок без чётких правил приоритетов.
  Когда процентные, фиксированные и подарочные акции применяются одновременно, а порядок их расчёта не определён — отладка превращается в хаос. Фиксируйте приоритеты и тестируйте комбинации до релиза.