A customer pays for an order, receives bonus points, then returns the product — the points are already spent. Without a proper cashback accrual architecture, e‑commerce stores on 1C-Bitrix lose up to 30% of revenue due to erroneous accruals and returns. According to the 1C-Bitrix documentation, the OnSaleOrderPaid event is the main trigger for awarding bonuses. We configure a flexible loyalty system: from the standard sale module bonuses to custom rules with categories, exclusions, and delayed confirmation. Over the years we have implemented more than 30 projects — from small shops with 500 items to catalogs of 100,000 positions. One client reduced operational return costs by 20%, and repeat purchases increased by 15%.
The standard mechanism awards points immediately after payment. Without two-step confirmation, order cancellation leads to cashback loss. The solution is an OnSaleOrderPaid handler with status check and subsequent confirmation on shipment. Let's look at both approaches.
How to set up cashback for different product categories?
Bitrix standard bonuses do not support category rules. For flexibility, you need a custom payment event handler. In the code, check the product's category and apply a specific percentage.
| Category | Cashback Percentage |
|---|---|
| Electronics | 2% |
| Clothing | 5% |
| Books | 7% |
\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderPaid', function (\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $userId = $order->getUserId(); $total = $order->getPrice(); // Cashback percentage from settings $percent = (float)\Bitrix\Main\Config\Option::get( 'local.cashback', 'base_percent', '3' ); $cashback = round($total * $percent / 100, 2); if ($cashback <= 0) { return; } \Local\Cashback\AccountManager::earn( $userId, $cashback, "Cashback {$percent}% for order #{$order->getId()}", $order->getId() ); } ); Additionally, you can add a check for the CASHBACK_EXCLUDED property for items with zero margin or promotions.
Why is two-step accrual important?
Accruing immediately after payment leads to losses on returns. The two-step approach:
- On payment — a transaction with status
pending. - On order fulfillment — confirmation (
confirmed). - On cancellation — reversal.
According to our projects, two-step accrual reduces errors by 30%. The investment in such development pays off in 2–3 months due to reduced returns.
// Confirm accrual on order fulfillment $em->addEventHandler('sale', 'OnSaleOrderStatusChange', function ($event) { $order = $event->getParameter('ENTITY'); if ($order->getField('STATUS_ID') === 'F') { \Local\Cashback\AccountManager::confirmByOrderId($order->getId()); } elseif ($order->getField('STATUS_ID') === 'X') { \Local\Cashback\AccountManager::cancelByOrderId($order->getId()); } }); For automatic cleanup of expired pending transactions, use an agent running once an hour. This prevents garbage accumulation in tables.
Comparison of two approaches:
| Criteria | Immediate accrual | Two-step accrual |
|---|---|---|
| Implementation simplicity | High | Medium |
| Risk on returns | High (points already awarded) | None |
| Impact on conversion | Instant motivation | Delayed but trust-based |
| Requires modifications | Minimum | Additional handlers and agents |
| The choice between immediate and two-step accrual depends on business requirements. Immediate accrual gives quick motivation but creates return risks. Two-step accrual requires extra logic but completely eliminates return errors and saves up to 20% of return budget. |
How to display cashback on the product card?
The buyer sees a cashback amount before checkout — this increases conversion.
// In product card template $price = \CPrice::GetBasePrice($elementId); $percent = (float)\Bitrix\Main\Config\Option::get('local.cashback', 'base_percent', '3'); $cashbackPreview = $price ? round($price['PRICE'] * $percent / 100, 0) : 0; <?php if ($cashbackPreview > 0): ?> <div class="cashback-preview"> Cashback: <strong><?= $cashbackPreview ?> rub.</strong> </div> <?php endif; ?> Which products are excluded from cashback?
Products, categories, or brands for which cashback is not awarded (already promotional items, zero margin goods). Implemented via the CASHBACK_EXCLUDED property:
function isExcludedFromCashback(int $productId): bool { $props = \CIBlockElement::GetProperty( CATALOG_IBLOCK_ID, $productId, [], ['CODE' => 'CASHBACK_EXCLUDED'] )->Fetch(); return $props && $props['VALUE'] === 'Y'; } The CASHBACK_EXCLUDED property (Yes/No type) is added to the catalog and set by the manager manually or during 1C import. Custom implementation scales 3 times better than standard bonuses when the catalog exceeds 10,000 items.
What is included in the work
- Audit of current Bitrix configuration and infoblock structure.
- Architectural design of accrual: tables, algorithms, handlers.
- Development of custom event handlers and agents.
- Configuration of exclusions and category rules.
- Integration with the template (product card, personal account).
- Testing on the live environment and documentation creation.
- 3-month stable operation guarantee.
- Training managers on the system.
Process
- Audit of current Bitrix configuration and infoblock structure.
- Architectural design of accrual: tables, algorithms, handlers.
- Development of custom event handlers and agents.
- Configuration of exclusions and category rules.
- Integration with the template (product card, personal account).
- Testing on the live environment and documentation creation.
- 3-month stable operation guarantee.
Estimated timelines
Basic setup (standard bonus mechanism) — from 1 hour. Custom solution with two-step accrual and exclusions — 1–2 working days. Turnkey integration — up to 3 days. The cost is calculated individually.
More than 5 years of 1C-Bitrix development experience. Certified specialists. Over 50 projects in loyalty system configuration.
Book a consultation — we will analyze your current system and propose the optimal accrual architecture. Get an accurate estimate of timelines and cost for your project.