Cumulative Discounts in 1C-Bitrix: Automation Without Headache
Imagine a client has made five purchases, totaling 80,000 rubles, but the system still treats them as a newbie. Without cumulative discounts, loyalty drops, and competitors poach. 1C-Bitrix lacks a built-in module for cascading discounts — custom logic is required every time. Over many years, our certified Bitrix developers have implemented this mechanic in 50+ projects: from stores with 10,000 clients to catalogs with millions of products. Solutions were tested under load and caching, so we share battle-proven approaches. Average order value increases by 15–20% after implementation, and savings on revisions during replication reach 25%. Typical implementation cost starts from $2,000, with guaranteed results.
What Approaches Are Used in Bitrix?
The first option is user groups with price binding. A hierarchy is created: "Base", "Silver" (5% discount), "Gold" (10%), "Platinum" (15%). Each group gets its own price in the trade catalog. Transition between groups is performed via the OnSaleOrderSaved event handler.
The second option is order discounts with the condition "Sum of paid orders". In the admin section "Store → Discounts", rules are created that automatically apply when the sum reaches a threshold. This method requires no code but lacks flexibility: you can't show a progress bar or attach additional conditions.
| Criterion | User Groups | Order Discounts |
|---|---|---|
| Flexibility | High — any conditions and combinations | Limited — only order sum |
| Performance | Faster — price taken from group | Slower — calculation on each cart |
| Progress display | Requires custom component | Not supported |
| Implementation complexity | Medium — handler + groups | Low — no code |
For clients with a large volume of orders, choose groups: they reduce server load. If volume is small and a progress bar isn't needed, order discounts suffice.
How to Set Up Automatic Group Transition?
The most reliable method is the OnSaleOrderSaved handler. Example code:
AddEventHandler('sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $userId = $order->getUserId(); // Calculate total sum of paid orders for the user $totalPaid = \Bitrix\Sale\Order::getList([ 'filter' => ['USER_ID' => $userId, 'PAYED' => 'Y'], 'select' => ['PRICE'], ])->fetchAll(); $total = array_sum(array_column($totalPaid, 'PRICE')); // Move to the appropriate group if ($total >= 50000) { CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [PLATINUM_GROUP_ID])); } elseif ($total >= 20000) { CUser::SetUserGroup($userId, array_merge(CUser::GetUserGroup($userId), [GOLD_GROUP_ID])); } }); The 1C-Bitrix documentation recommends moving heavy logic to agents. Crucially, recalculation should only happen for paid orders; otherwise, discounts are awarded on incomplete purchases. Also, always clear the user group cache using CCacheManager::ClearByTag("USER_GROUPS_".$userId).
Why Are User Groups Faster Than Order Discounts?
On each cart render, order discounts query purchase history. On a catalog of 50,000 items, this introduces noticeable lag. Groups store the discount once in the b_user_group table — prices are fetched immediately. For high-traffic projects, groups are the only option without performance degradation.
How to Avoid Performance Degradation on 10,000+ Clients?
The OnSaleOrderSaved handler can cause delays. Solution: move recalculation to an agent that runs once an hour. The agent collects all paid orders from the last 60 minutes and updates groups in bulk. Additionally, use tagged caching: attach the tag USER_GROUPS_{userId} to all cached components with prices.
| Problem | Solution |
|---|---|
| Slow recalculation after each order | Agent with batch updates |
| Stale prices in cache | Tagged caching + cache clearing by tag |
| Discount reduction due to coupons | Exclude coupons from the calculation formula |
Setup Process for Cumulative Discounts: From Analysis to Deployment
- Analysis — we study average order value (e.g., 80,000 rubles), purchase frequency (2–3 orders per month), define 5 discount thresholds (5%, 10%, 15%, 20%, 25%).
- Design — choose the approach (groups or discounts), design the group structure and price binding for 100,000 items.
- Implementation — write the handler or configure discounts, add a progress bar in the personal account showing the current total (e.g., "5,000 rubles left until 15% discount").
- Testing — simulate 200+ orders in a test environment, verify correct transition with 10,000 users.
- Deployment — push to production, configure caching, provide monitoring recommendations.
Deliverables
- Creation of user groups and price binding (if groups method is chosen).
- Development of the
OnSaleOrderSavedhandler with deduplication and caching. - Configuration of order discounts (if discounts method is chosen).
- Development of the progress bar component for the personal account.
- Detailed technical documentation and admin access.
- 1 month of post-deployment support and bug fixes.
- Training for up to 3 managers on manual discount management.
Our certified Bitrix developers guarantee seamless integration with 10+ years of experience in e-commerce. You can learn more about our expertise in loyalty programs at Wikipedia.
Want to increase average order value by 30% with cumulative discounts? Contact us for a consultation — we’ll discuss your store’s specifics.
Typical Implementation Mistakes
- Including all orders, including unpaid ones. This leads to false threshold achievement. Use the
PAYED = 'Y'flag. - Ignoring caching. Without clearing the user’s cache, the new price won’t apply until the next login.
- Lack of manual transition capability. Administrators need an interface to manually upgrade a client’s status.
Order cumulative discount setup and get a ready-made solution for your online store.