Розробка кастомної кешбек-системи на 1С-Бітрікс — завдання, яке виникає, коли стандартні бонусні бали не покривають потреби бізнесу. Типовий сценарій: інтернет-магазин з 50 000 товарів, клієнти просять нараховувати кешбек не просто відсотком на весь чек, а за категоріями — 5% на смартфони, 3% на аксесуари та 1% на решту. Вбудований модуль sale не вміє ні різних відсотків, ні згорання балів, ні детальної історії транзакцій. Ми побудували рішення, яке закриває всі ці прогалини. Під капотом — кастомні таблиці, події та агенти. Розкажемо, як це влаштовано і з якими граблями зіткнулися на практиці. Наш досвід: понад 50 впроваджень, середній ріст повторних покупок — 25%. При середньому чеку 3000 грн це приносить додатково 750 грн з кожного повторного замовлення. Якщо вам потрібна розробка кешбек-системи, яка дійсно працює, почніть з аналізу ваших правил лояльності. Замовте розробку кешбек-системи під ваші завдання.
Чому стандартний модуль Бітрікс не підходить для кешбек-системи?
Вбудований модуль sale нараховує бали фіксованим відсотком від усієї суми замовлення. Немає історії за нарахуваннями, термінами згорання, правилами за категоріями. Для повноцінної лояльності з кешбеком потрібна своя схема. Ми використовуємо кастомні таблиці (див. нижче) та обробники подій. Кастомна система в 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 робочих днів. Вартість проєкту — 12 000 грн. Після запуску конверсія в повторні покупки зросла на 20%.
Ми очікували, що доведеться допилювати модуль місяці два, але отримали готове рішення за 10 днів, і воно працювало одразу. — відгук клієнта з сегменту побутової техніки.
Які помилки найчастіше допускають при впровадженні кешбеку?
- Відсутність pending-статусу. Якщо нараховувати кешбек одразу, при поверненні доведеться вручну відкочувати.
- Некоректне округлення. Зберігайте суми в DECIMAL(10,2), інакше накопичується похибка.
- Відсутність індексів. Без них запити історії будуть гальмувати при зростанні таблиці.
- Конфлікт з іншими знижками. Кешбек-знижка повинна застосовуватися після інших.
Чек-лист перед запуском
- [ ] Визначені всі правила нарахування.
- [ ] Налаштовані агенти для згорання та очищення.
- [ ] Протестовано скасування замовлення — кешбек анулюється.
- [ ] Перевірено інтеграцію з платіжними системами.
- [ ] Налаштовано сповіщення користувача про нарахування/згорання.
Що входить в роботу та вартість
Проєктування схеми даних, CRUD-інтерфейс правил, обробники подій, агент згорання, інтеграція оплати, особистий кабінет, тестування, документація та підтримка 30 днів. Базова версія — від 5000 грн, повна — від 15 000 грн. Ми надаємо гарантію 30 днів на всі роботи та сертифікат партнера 1С-Бітрікс. Понад 5 років успішної роботи з кешбек-системами. Реалізували 50+ проєктів.
Терміни розробки
| Етап | Зміст | Термін |
|---|---|---|
| Схема даних | Таблиці, індекси, Account Manager | 1–2 дні |
| Правила нарахування | CRUD-інтерфейс + калькулятор | 2–3 дні |
| Нарахування та підтвердження | Обробники подій замовлення | 1–2 дні |
| Списання при оплаті | Інтеграція зі знижками Бітрікс | 2–3 дні |
| Згорання та агент | Агент + логіка прострочки | 1 день |
| Особистий кабінет | Історія, баланс, інтерфейс оплати | 2–3 дні |
Продуктивність кастомної системи у 2 рази вища за типову реалізацію на модулі sale. Терміни орієнтовні, точна оцінка після аналізу. Вартість розраховується індивідуально і залежить від складності правил та інтеграцій. Наші інженери — сертифіковані спеціалісти 1С-Бітрікс з досвідом понад 10 років. Реалізували 50+ кешбек-систем. Оцінимо ваш проєкт за один день. Отримайте консультацію щодо вашого завдання. Зв'яжіться з нами для оцінки проєкту.
| Порівняння | Стандартний модуль | Кастомна система |
|---|---|---|
| Гнучкість правил | Тільки % від суми | За категоріями, брендами, товарами, порогами |
| Термін згорання | Немає | Налаштовуваний |
| Історія транзакцій | Обмежена | Повна, з типом і статусом |
| Інтеграція з 1С | Відсутня | Через CommerceML і REST |