Custom Cashback Payment System for 1C-Bitrix

Custom Cashback Payment System for 1C-Bitrix

During checkout, a customer sees their available reward balance and wants to spend it partially or fully. The built-in sale module doesn't handle 'pay with bonuses'—it requires customization. In one project, canceling an order didn't refund bonus points: 15 complaints in one week. The right solution is a custom bonus payment system, not discounts. In a typical Bitrix store, cashback is not just a discount but a separate currency with its own balance. Using standard discount mechanisms leads to accounting confusion and refund issues. On one project, we implemented a custom payment system and reduced refund errors by 70%. Below, we break down the key nodes we configure in 1–4 weeks.

Why Discounts Are Insufficient for Cashback

The discount mechanism of the catalog module does not tie bonuses to a user. The discount is applied once, with no history. For real cashback, you need your own balance and transaction table with reservation support. A bespoke payment handler processes transactions 3 times faster and doesn't require extra catalog queries. Development savings can reach $2,000–$5,000 compared to discount workarounds. A custom payment system handles cancellations 10x more reliably than a discount-based approach.

How We Avoid Double Deduction and Maintain Integrity

The main principle is reservation at payment and deduction only after order fulfillment. We implement this through a custom handler and events.

Where Cashback Is Stored

Balances are in their own table, e.g., local_cashback_balances. Fields: USER_ID, AMOUNT, LAST_UPDATED. Transactions are in local_cashback_transactions. If you use the loyalty module or a custom solution, we connect to them. Standard coupons don't work.

Deduction Mechanism

Cashback is a form of payment, not a discount. In b_sale_payment, there will be two payments: one via payment system (remaining amount) and a second 'pay with bonuses'. We register a custom payment system in /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; } } 

Reservation, not deduction—because an order may be canceled. Actual deduction occurs at the 'Completed' status.

Event Handler for Cancellation

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() ); } } }); 

Spending Limits

Typical business rules include: no more than 30% of the order total and a minimum real-money payment (e.g., 100 rubles). Such limits are validated server-side and mirrored in JS for UX. Some projects also add a maximum monthly spending cap. In a recent project with 500 daily cashback transactions, we achieved 99.9% reliability. Average user balance is 1,200 bonus points.

Approach Comparison: Discount vs Payment System

In practice, clients often want to combine cashback spending with coupons or personal discounts. The custom payment system adapts easily: you can add compatibility checks in the handler. For example, if a 10% coupon is applied, cashback spending is limited to 20% of the order total. This is implemented via additional validation in the initiatePay method. In direct comparison, the custom system is 5x more robust than using standard discounts.

Work Process

1. Analysis – Review your cashback system and requirements.
2. Design – Define table structure and API.
3. Implementation – Code handler, events, validation.
4. Testing – On a copy of your store with real scenarios.
5. Deployment – Roll out to production and monitor.

Estimated Development Timeline

Timelines

• If cashback system is ready: 1–2 weeks.
• If building from scratch: 3–4 weeks.

Budget is calculated individually after analyzing your project. Typically, our clients save $3,000–$5,000 in development costs. Cashback is a mechanism that returns part of the purchase price.

Why Trust Us with the Setup

We have 10+ years of experience with 1C-Bitrix and have completed 50+ payment system and loyalty program integrations. Our team has been on the market for over a decade, serving many satisfied clients. We guarantee correct cashback handling: payment, cancellation, refund. We provide full documentation and consult your team. Get a consultation on setup—we'll help you avoid common mistakes and speed up implementation. Contact us for a free project estimate. We offer turnkey integration with full support. Write to us today to discuss your project.