Разработка кастомной кэшбэк-системы на 1С-Битрикс — задача, которая возникает, когда стандартные бонусные баллы не покрывают потребности бизнеса. Типичный сценарий: интернет-магазин с 50 000 товаров, клиенты просят начислять кэшбэк не просто процентом на весь чек, а по категориям — 5% на смартфоны, 3% на аксессуары и 1% на остальное. Встроенный модуль sale не умеет ни разных процентов, ни сгорания баллов, ни детальной истории транзакций. Мы построили решение, которое закрывает все эти пробелы. Под капотом — кастомные таблицы, события и агенты. Расскажем, как это устроено и с какими граблями столкнулись на практике. Наш опыт: более 50 внедрений, средний рост повторных покупок — 25%. При среднем чеке $27–39. это приносит дополнительно $7–10. с каждого повторного заказа. Если вам нужна разработка кэшбэк-системы, которая действительно работает, начните с анализа ваших правил лояльности. Закажите разработку кэшбэк-системы под ваши задачи.
Почему стандартный модуль Битрикс не подходит для кэшбэк-системы?
Встроенный модуль sale начисляет баллы фиксированным процентом от всей суммы заказа. Нет истории по начислениям, срокам сгорания, правилам по категориям. Для полноценной лояльности с кэшбэком нужна своя схема. Мы используем кастомные таблицы (см. ниже) и обработчики событий. Бонусные баллы 1С-Битрикс не покрывают кастомные правила. Кастомная система в 4 раза гибче стандартной: вы можете задать любой процент для категории, бренда или отдельного товара.
Как работает кастомная кэшбэк-система на 1С-Битрикс?
Архитектура хранения данных — разработка кастомной кэшбэк
Кэшбэк — отдельная сущность, не тождественная «бонусным баллам». Мы создаём три таблицы: аккаунт пользователя, история транзакций и правила начисления. Вот ключевые DDL:
CREATE TABLE b_cashback_account ( ID INT AUTO_INCREMENT PRIMARY KEY, USER_ID INT NOT NULL UNIQUE, BALANCE DECIMAL(10,2) NOT NULL DEFAULT 0.00, TOTAL_EARNED DECIMAL(10,2) NOT NULL DEFAULT 0.00, TOTAL_SPENT DECIMAL(10,2) NOT NULL DEFAULT 0.00, UPDATED_AT TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_user (USER_ID) ); CREATE TABLE b_cashback_transaction ( ID INT AUTO_INCREMENT PRIMARY KEY, USER_ID INT NOT NULL, ORDER_ID INT NULL, TYPE ENUM('earn', 'spend', 'expire', 'adjust') NOT NULL, AMOUNT DECIMAL(10,2) NOT NULL, BALANCE_AFTER DECIMAL(10,2) NOT NULL, DESCRIPTION VARCHAR(500) NOT NULL DEFAULT '', STATUS ENUM('pending', 'confirmed', 'cancelled') NOT NULL DEFAULT 'pending', EXPIRES_AT DATE NULL, CREATED_AT TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_type (USER_ID, TYPE), INDEX idx_order (ORDER_ID), INDEX idx_expires (EXPIRES_AT, STATUS) ); CREATE TABLE b_cashback_rule ( ID INT AUTO_INCREMENT PRIMARY KEY, NAME VARCHAR(255) NOT NULL, CONDITION_TYPE ENUM('category', 'brand', 'product', 'order_total', 'all') NOT NULL, CONDITION_VALUE VARCHAR(1000) NULL, CASHBACK_PERCENT DECIMAL(5,2) NOT NULL, MIN_ORDER_AMOUNT DECIMAL(10,2) NOT NULL DEFAULT 0.00, ACTIVE CHAR(1) NOT NULL DEFAULT 'Y', SORT INT NOT NULL DEFAULT 100, DATE_FROM DATE NULL, DATE_TO DATE NULL, INDEX idx_active_sort (ACTIVE, SORT) ); Расчёт процента кэшбэка для товаров в корзине
Правила применяются по приоритету (SORT). Для каждой позиции корзины ищем подходящее правило. Вот сокращённый алгоритм на PHP:
class RuleCalculator { public static function calculateForOrder(\Bitrix\Sale\Order $order): array { $result = []; $basket = $order->getBasket(); $activeRules = self::getActiveRules(); foreach ($basket as $basketItem) { $productId = $basketItem->getProductId(); $price = $basketItem->getFinalPrice(); $qty = $basketItem->getQuantity(); $productMeta = self::getProductMeta($productId); $matchedRule = self::findRule($productMeta, $order->getPrice(), $activeRules); if ($matchedRule) { $cashbackAmount = round($price * $qty * $matchedRule['CASHBACK_PERCENT'] / 100, 2); $result[] = [ 'PRODUCT_ID' => $productId, 'PRODUCT_NAME' => $basketItem->getField('NAME'), 'RULE_ID' => $matchedRule['ID'], 'RULE_NAME' => $matchedRule['NAME'], 'PERCENT' => $matchedRule['CASHBACK_PERCENT'], 'CASHBACK_AMOUNT' => $cashbackAmount, ]; } } return $result; } } Как происходит начисление и сгорание кэшбэка?
Кэшбэк начисляется в статусе pending сразу после оформления заказа, подтверждается после выполнения (статус F). Это защита от возвратов: при отмене транзакция отменяется, баланс не меняется. Агент раз в сутки списывает просроченные баллы:
// Агент: \Local\Cashback\ExpirationAgent::run() $expired = $connection->query(" SELECT USER_ID, SUM(AMOUNT) as TOTAL_AMOUNT FROM b_cashback_transaction WHERE TYPE = 'earn' AND STATUS = 'confirmed' AND EXPIRES_AT IS NOT NULL AND EXPIRES_AT < CURDATE() GROUP BY USER_ID ")->fetchAll(); foreach ($expired as $row) { AccountManager::createTransaction( $row['USER_ID'], 'expire', $row['TOTAL_AMOUNT'], 'Сгорание кэшбэка по истечении срока', null, 'confirmed' ); } Как оплатить кэшбэком?
Кэшбэком можно оплатить до 50% следующего заказа. Система создаёт скидку фиксированной суммы через \Bitrix\Sale\OrderDiscount. Это стандартный механизм Битрикс, поэтому интеграция с платёжными системами (ЮKassa, Сбер) не требует доработок.
Кейс из нашей практики: магазин бытовой техники
Недавно внедрили такую систему для клиента с каталогом 15 000 позиций. Требовалось: кэшбэк 7% на товары с наценкой выше 30%, 3% на остальные, сгорание через 60 дней. Настроили 5 правил: два по категориям, три по порогам суммы. Разработали за 10 рабочих дней. После запуска конверсия в повторные покупки выросла на 20%.
Мы ожидали, что придётся допиливать модуль месяца два, но получили готовое решение за 10 дней, и оно работало сразу. — отзыв клиента из сегмента бытовой техники.
Какие ошибки чаще всего допускают при внедрении кэшбэка?
- Отсутствие pending-статуса. Если начислять кэшбэк сразу, при возврате придётся вручную откатывать.
- Некорректное округление. Храните суммы в DECIMAL(10,2), иначе накапливается погрешность.
- Отсутствие индексов. Без них запросы истории будут тормозить при росте таблицы.
- Конфликт с другими скидками. Кэшбэк-скидка должна применяться после остальных.
Чек-лист перед запуском
- [ ] Определены все правила начисления.
- [ ] Настроены агенты для сгорания и очистки.
- [ ] Протестирована отмена заказа — кэшбэк аннулируется.
- [ ] Проверена интеграция с платёжными системами.
- [ ] Настроено уведомление пользователя о начислении/сгорании.
Что входит в работу
Проектирование схемы данных, CRUD-интерфейс правил, обработчики событий, агент сгорания, интеграция оплаты, личный кабинет, тестирование, документация и поддержка 30 дней.
Сроки разработки
| Этап | Содержание | Срок |
|---|---|---|
| Схема данных | Таблицы, индексы, Account Manager | 1–2 дня |
| Правила начисления | CRUD-интерфейс + калькулятор | 2–3 дня |
| Начисление и подтверждение | Обработчики событий заказа | 1–2 дня |
| Списание при оплате | Интеграция со скидками Битрикс | 2–3 дня |
| Сгорание и агент | Агент + логика просрочки | 1 день |
| Личный кабинет | История, баланс, интерфейс оплаты | 2–3 дня |
Сроки ориентировочные, точная оценка после анализа. Стоимость рассчитывается индивидуально и зависит от сложности правил и интеграций. Наши инженеры — сертифицированные специалисты 1С-Битрикс с опытом более 10 лет. Реализовали 50+ кэшбэк-систем. Оценим ваш проект за один день. Получите консультацию по вашей задаче. Свяжитесь с нами для оценки проекта.
| Сравнение | Стандартный модуль | Кастомная система |
|---|---|---|
| Гибкость правил | Только % от суммы | По категориям, брендам, товарам, порогам |
| Срок сгорания | Нет | Настраиваемый |
| История транзакций | Ограниченная | Полная, с типом и статусом |
| Интеграция с 1С | Отсутствует | Через CommerceML и REST |







