Баллы списались дважды: где ломается программа лояльности под нагрузкой

Покупатель применяет бонусы в корзине, повторяет запрос после зависания и видит, что баланс изменился дважды. В поддержку уходит сообщение: «Баллы списались дважды». На пике акции одна такая цепочка быстро превращается в очередь из одинаковых обращений.

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

Я Антон Фокин, CEO Qtim. Разберу программу лояльности как операционный контур: где появляются двойные списания, почему балансу нужна история событий, что делать с возвратами и какие решения принять до первой массовой акции.

На кону — повторные покупки. В Consumer Loyalty Program Survey 2025 компания Deloitte опросила 5564 взрослых участника программ лояльности в США с сентября по октябрь 2025 года. Среди респондентов, отвечавших о программе любимого бренда, 72% сообщили, что она повышает вероятность покупок у этого бренда, а 56% — что благодаря ей тратят больше. Эти проценты относятся к американской выборке и любимым программам респондентов. Для нас важен масштаб ставки: программа влияет на выбор магазина и размер покупки.

Баллы проходят через профиль, корзину, оплату и возврат

На экране программа лояльности выглядит компактно: баланс, условия акции и кнопка «Списать». За этой кнопкой встречаются профиль покупателя, правила кампании, корзина, заказ, платёж, возврат, CRM, аналитика и поддержка. У каждой системы свой момент обновления.

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

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

Главный вопрос звучит так: какая система имеет право окончательно изменить бонусный счёт? Если такого владельца нет, сайт, мобильное приложение, касса и CRM могут прислать несколько команд об одной покупке.

Повторный запрос должен вернуть прежний результат

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

AWS описывает безопасные повторы через идемпотентные API: клиент передаёт уникальный идентификатор запроса, а сервис распознаёт повтор и возвращает результат уже выполненной операции. Запись идентификатора и изменение данных должны происходить атомарно — целиком или никак.

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

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

Одна цифра баланса скрывает историю операций

Поле «Баланс: 2400» отвечает только на вопрос «сколько сейчас». Поддержке нужны причины: за какой заказ начислили бонусы, что уже потрачено, какой резерв ещё действует, когда сгорела часть суммы и какое событие исправило ошибку.

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

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

Исправление тоже становится событием. Если оператор просто меняет число в профиле, причина исчезает. Компенсирующая запись сохраняет исходную операцию, автора, основание и результат.

Возврат проверяет программу строже, чем начисление

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

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

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

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

При перегрузке заранее решают, что увидит покупатель

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

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

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

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

4fresh и Стадикэтс: внутренняя валюта связывает продукт целиком

В кейсе 4fresh команда Qtim переносила интернет-магазин с 1С-Битрикс на собственное решение и развивала систему лояльности: внутреннюю валюту, программы приглашений и премиум-клуб. Одновременно переносились профили пользователей и история заказов. Такая задача связывает бонусные правила с данными клиента и коммерческим контуром магазина.

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

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

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

Шесть проверок до первой массовой акции

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

1. Событие. Какое действие создаёт начисление, резерв, списание, отмену и компенсацию?
2. Источник. Какая система хранит окончательную историю бонусных операций?
3. Повтор. Как один запрос распознаётся во всех связанных сервисах?
4. Состояние. Какие промежуточные статусы увидят покупатель, поддержка и аналитика?
5. Возврат. Как полная и частичная отмена меняют начисленные и потраченные бонусы?
6. Сбой. Что произойдёт с заказом, если бонусный сервис, касса или интеграция временно недоступны?

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

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

Если баллы меняют чек, им нужен денежный контур

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

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

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