Списання кешбеку в 1С-Бітрікс: кастомна платіжна система

Налаштування списання кешбеку при оплаті в 1С-Бітрікс

При оформленні замовлення покупець бачить доступний баланс кешбеку та хоче списати його частково або повністю. Вбудований модуль sale не вміє «оплату бонусами» — потрібне доопрацювання. В одному проєкті при скасуванні замовлення кешбек не повертався: за тиждень надійшло 15 скарг. Правильне рішення — кастомна платіжна система, а не знижки. У типовому магазині на Бітрікс кешбек — це не просто знижка, а окрема валюта з власним балансом. Використання стандартних механізмів знижок призводить до плутанини в обліку та складнощів із поверненнями. На одному з проєктів ми впровадили кастомну платіжну систему та скоротили кількість помилок із поверненнями на 70%. Нижче розберемо ключові вузли, які ми налаштовуємо за 1–4 тижні.

Чому кешбек не можна реалізувати через знижки?

Механізм знижок модуля catalog не прив'язує бонуси до користувача. Знижка застосовується разово, немає історії. Для реального кешбеку потрібна власна таблиця балансів і транзакцій із підтримкою резервування. Кастомна платіжна система обробляє транзакції в 3 рази швидше та не потребує зайвих запитів до каталогу. Економія на розробці може досягати 40% порівняно з костилями на знижках.

Як уникнути подвійного списання та зберегти цілісність?

Головний принцип — резервування при оплаті та списання тільки після виконання замовлення. Реалізуємо через кастомний обробник і події.

Де зберігається кешбек

Баланси — у власній таблиці, наприклад local_cashback_balances. Поля: USER_ID, AMOUNT, LAST_UPDATED. Транзакції — у local_cashback_transactions. Якщо використовуєте модуль loyalty або кастомне рішення — підключаємося до них. Стандартні купони не підходять.

Механізм списання

Кешбек — форма оплати, а не знижка. У b_sale_payment буде два платежі: один через платіжну систему (сума, що залишилася), другий — «оплата бонусами». Реєструємо кастомну платіжну систему в /local/php_interface/include/sale_payment/cashback/handler.php:

class CashbackPaySystemHandler extends \Bitrix\Sale\PaySystem\ServiceHandler { public function initiatePay( \Bitrix\Sale\Payment $payment, \Yii\HttpRequest $request = null ): \Bitrix\Sale\PaySystem\ServiceResult { $result = new \Bitrix\Sale\PaySystem\ServiceResult(); $userId = $payment->getOrder()->getUserId(); $amount = $payment->getSum(); // Check balance $balance = CashbackBalanceTable::getBalance($userId); if ($balance < $amount) { $result->addError(new \Bitrix\Main\Error('Недостатньо кешбеку')); return $result; } // Reserve CashbackBalanceTable::reserve($userId, $amount, $payment->getId()); $payment->setPaid('Y'); $payment->save(); return $result; } } 

Резервування, а не списання — тому що замовлення можуть скасувати. Фактичне списання відбувається при статусі «Виконано».

Обробник події скасування

AddEventHandler('sale', 'OnSaleOrderCanceled', function(\Bitrix\Sale\Order $order) { foreach ($order->getPaymentCollection() as $payment) { if ($payment->getPaySystem()->getField('CODE') === 'cashback') { CashbackBalanceTable::releaseReserve( $order->getUserId(), $payment->getSum(), $payment->getId() ); } } }); 

Обмеження суми списання

Типові правила: не більше 30% суми замовлення, мінімальна оплата грошима — 100 гривень. Ліміти перевіряються на сервері та дублюються в JS. Приклад серверної валідації:

$maxCashbackAllowed = min( $order->getPrice() * 0.30, CashbackBalanceTable::getBalance($userId), $order->getPrice() - 100 ); 

Значення передається в JS через data-max-cashback. Такий підхід запобігає зловживанням і зберігає маржинальність.

Порівняння підходів: знижка vs платіжна система

На практиці часто трапляються ситуації, коли клієнт хоче комбінувати списання кешбеку з купонами або персональними знижками. Кастомна платіжна система легко адаптується: можна додати перевірку на сумісність з іншими акціями прямо в обробнику. Наприклад, якщо застосовано купон на 10%, списання кешбеку обмежується 20% від суми замовлення. Це реалізується через додаткову валідацію в методі initiatePay.

Що входить у роботу?

• Аудит поточної системи кешбеку (якщо є) або проєктування з нуля.
• Розробка кастомної платіжної системи з резервуванням.
• Інтеграція з кошиком (sale.order.ajax або кастомний компонент).
• Налаштування обмежень списання (відсотки, мінімальна сума).
• Документація щодо обробника, подій та адміністрування.
• Навчання менеджерів: повернення, скасування, звітність.
• Підтримка після деплою (2 тижні безкоштовно).

Процес роботи

1. Аналітика — розбираємо вашу систему кешбеку та вимоги.
2. Проєктування — визначаємо структуру таблиць та API.
3. Реалізація — пишемо код обробника, подій, валідації.
4. Тестування — на копії магазину з реальними сценаріями.
5. Деплой — викатка на бой та моніторинг.

Приблизні терміни розробки

Терміни орієнтовно

• Якщо система кешбеку вже готова: 1–2 тижні.
• Якщо розробляється з нуля: 3–4 тижні.

Бюджет розраховується індивідуально після аналізу вашого проєкту. Кешбек — механізм повернення частини вартості товару.

Чому варто довірити налаштування нам

Працюємо з 1С-Бітрікс більше 10 років, виконали 50+ інтеграцій платіжних систем та бонусних програм. Гарантуємо коректну обробку кешбеку: оплата, скасування, повернення. Надаємо повну документацію та консультуємо команду. Отримайте консультацію з налаштування — ми допоможемо уникнути типових помилок та прискорити впровадження. Замовте дзвінок — обговоримо ваш проєкт.