Розробка кастомної кешбек-системи на 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 |







