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

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

Какие состояния нужны бонусной операции

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

Для проектирования CRM Lab предлагает следующий минимальный набор состояний.

СостояниеЧто означаетЧто происходит при возврате
Ожидает доступностиБаллы рассчитаны, но потратить их пока нельзяОтменяем соответствующую часть ожидаемого начисления
ДоступноВознаграждение можно использоватьСоздаём обратную операцию по правилам программы
ПотраченоБаллы использованы в другом заказеПрименяем заранее определённое правило недостаточного остатка
ВосстановленоВернули баллы, которыми оплатили отменённую покупкуСохраняем связь с исходным списанием и срок действия

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

Как обработать частичный возврат

Условный пример. Заказ состоит из двух товаров: 6 000 и 4 000 рублей после обычных скидок. В этой учебной модели начисление составляет 5% от цены товаров до оплаты старыми баллами, то есть 500 баллов. При возврате второго товара отменяем его начисление — 200 баллов. Оставшиеся 300 относятся к сохранённой покупке. В реальной программе база начисления может быть другой.

Если клиент одновременно потратил 1 000 старых баллов, заранее определите, как они распределяются по позициям. При пропорциональном распределении на возвращаемый товар приходится 400 баллов. Эти 400 восстанавливаются отдельно; они не заменяют отмену новых 200. Денежный возврат рассчитывает учётная система по фактической оплате позиции.

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

Что делать, если баллы уже потрачены

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

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

Сообщение клиенту должно показывать причину: «После возврата товара мы отменили 200 начисленных за него баллов и восстановили 400 баллов, использованных при оплате». Одно итоговое изменение на 200 не объясняет, что произошло.

Какие данные передать разработчику

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

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

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

Источники

CleverTap. Reverse/Refund Points. CleverTap Developer Documentation. Проверено 22.09.2026.