Разработка кастомной кэшбэк-системы на 1С-Битрикс — задача, которая возникает, когда стандартные бонусные баллы не покрывают потребности бизнеса. Типичный сценарий: интернет-магазин с 50 000 товаров, клиенты просят начислять кэшбэк не просто процентом на весь чек, а по категориям — 5% на смартфоны, 3% на аксессуары и 1% на остальное. Встроенный модуль sale не умеет ни разных процентов, ни сгорания баллов, ни детальной истории транзакций. Мы построили решение, которое закрывает все эти пробелы. Под капотом — кастомные таблицы, события и агенты. Расскажем, как это устроено и с какими граблями столкнулись на практике. Наш опыт: более 50 внедрений, средний рост повторных покупок — 25%. При среднем чеке 3000 руб. это приносит дополнительно 750 руб. с каждого повторного заказа. Если вам нужна разработка кэшбэк-системы, которая действительно работает, начните с анализа ваших правил лояльности. Закажите разработку кэшбэк-системы под ваши задачи.
Почему стандартный модуль Битрикс не подходит для кэшбэк-системы?
Встроенный модуль 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 |