Как настроить начисление бонусных баллов после покупки

После старта бот отправляет благодарность за покупку и сообщение о расчёте кэшбэка. Следующий узел mathOperation выполняет purchase_amount × 0.1 и записывает результат в cashback_earned. Потом второй математический узел складывает loyalty_balance и cashback_earned, сохраняя итог снова в loyalty_balance. Эти две операции разделены, поэтому в сообщении можно показать как начисление, так и общий баланс.

Далее отправляется сообщение с {{cashback_earned}} и {{loyalty_balance}}, добавляется тег loyalty_cashback_received, затем ветка завершается. Встроенный текст говорит о 10% и содержит утверждение "1 балл = 1 ₽". Оно согласовано с демонстрационным сценарием, но не устанавливает правила вашей программы. Измените сообщение, коэффициент и правила списания вместе, если у вас другая модель расчёта.

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

• Определите единственный источник purchase_amount и его денежную единицу.
• Запускайте поток только после события, которое ваша система считает успешной оплатой.
• Согласуйте процент, правила округления и срок действия баллов.
• Отдельно опишите, как корректируется баланс при возврате или отмене заказа.

Переменная purchase_amount — это сумма, от которой шаблон считает 10%. В сиде не видно, откуда она приходит, поэтому не нужно подставлять число вручную как постоянное значение для настоящих заказов. Решите, какая система передаёт сумму, в каком формате она делает это и содержит ли сумма доставку, скидку, налоги или другие исключения. Один и тот же бизнес-термин должен означать одинаковую сумму и в оплате, и в начислении.

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

Для примера: если правило вашей программы действительно даёт 10% от подходящей суммы, то шаблон использует множитель 0.1. Это не рекомендация размера вознаграждения и не обещание выгоды покупателю. Перед публикацией проверьте, как система показывает дробные результаты, и установите правило округления. Иначе пользователь и оператор могут увидеть разные числа для одной и той же покупки.

1. 01

   Зафиксируйте событие оплаты

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

2. 02

   Передайте сумму и баланс

   Проверьте, что purchase_amount и loyalty_balance числовые и относятся к одному пользователю. Задайте правила для пустых и ошибочных значений.

3. 03

   Настройте коэффициент и текст

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

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

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

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

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

Фраза "1 балл = 1 ₽" применима только там, где это действительно утверждённое условие. В иных программах баллы могут иметь другой коэффициент, ограничения на категории или минимальную сумму списания. Не переносите в своё сообщение цену, курс балла, названия магазина или срок из чужого примера. Любое такое значение должно быть проверено владельцем программы до публикации.

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

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

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

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

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