Flexible Cashback Rules by Category in 1C-Bitrix

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Flexible Cashback Rules by Category in 1C-Bitrix
Simple
~1 day
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1358
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    830
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1075

A marketer wants to give 5% cashback on electronics, 2% on household chemicals, and 0% on promotional items. The rules should combine: a 'Gold' loyalty card adds +1% to the base rate in any category. The standard discount module (catalog.discount) is not suitable – it operates on price reduction, not account credits. A separate rule system is needed. Without it, marketers manually adjust orders, errors grow, and customers are unhappy. Our team developed a cashback rule module that can be flexibly configured for any loyalty program. This article provides ready-made architecture and PHP code for 1C-Bitrix. Get a consultation on implementation – we will help adapt the solution to your catalog.

Architecture of Accrual Rules

Rules are stored in the local_cashback_rules table. Minimal structure:

CREATE TABLE local_cashback_rules (
    ID           INT AUTO_INCREMENT PRIMARY KEY,
    RULE_TYPE    ENUM('category','product','user_group','promo') NOT NULL,
    ENTITY_ID    INT,           -- ID of infoblock section, product, or group
    CASHBACK_PCT DECIMAL(5,2),  -- accrual percentage
    PRIORITY     INT DEFAULT 10,-- lower number = higher priority
    DATE_FROM    DATE,
    DATE_TO      DATE,
    ACTIVE       CHAR(1) DEFAULT 'Y'
);

Rules with RULE_TYPE = 'category' are attached to catalog infoblock sections. When calculating cashback for an order, we need to determine which section each product belongs to and find the matching rule. More about the discount system.

Determining the Product Category for Cashback

A product can be linked to multiple sections (multiple binding). For rule selection, we use the 'primary' section:

function getCashbackRateForProduct(int $productId): float
{
    // Primary section via b_iblock_element
    $element = \CIBlockElement::GetByID($productId)->Fetch();
    $sectionId = (int)$element['IBLOCK_SECTION_ID'];

    // Look for rule: first by exact section, then by parents
    while ($sectionId > 0) {
        $rule = CashbackRuleTable::getActiveRuleForSection($sectionId);
        if ($rule) {
            return (float)$rule['CASHBACK_PCT'];
        }

        // Move up the section tree
        $section = \CIBlockSection::GetByID($sectionId)->Fetch();
        $sectionId = (int)$section['IBLOCK_SECTION_ID'];
    }

    // Default rule
    return CashbackConfig::getDefaultRate();
}

Rule inheritance along the section tree: if 'Electronics' has 5% and 'Laptops' has no explicit rule – laptops get the 5% from the parent section. An explicit rule on a child section always overrides the parent.

Priority and Combining Rules

Complex logic with multiple simultaneously active rules – via priorities:

function resolveCashbackRate(int $productId, int $userId): float
{
    $baseRate = getCashbackRateForProduct($productId);

    // Additional rules by user group
    $userGroups = CUser::GetUserGroup($userId);
    $bonusRates = [];

    foreach ($userGroups as $groupId) {
        $rule = CashbackRuleTable::getQuery()
            ->setFilter([
                'RULE_TYPE'  => 'user_group',
                'ENTITY_ID'  => $groupId,
                'ACTIVE'     => 'Y',
                '<=DATE_FROM' => new \Bitrix\Main\Type\Date(),
                '>=DATE_TO'   => new \Bitrix\Main\Type\Date(),
            ])
            ->setOrder(['PRIORITY' => 'ASC'])
            ->fetchObject();

        if ($rule) {
            $bonusRates[] = (float)$rule->getCashbackPct();
        }
    }

    // Strategy: take the maximum group bonus + base category rate
    $bonusRate = empty($bonusRates) ? 0 : max($bonusRates);

    return $baseRate + $bonusRate;
}

The business chooses the strategy: addition or replacement. For most loyalty programs: category rate + group bonus (addition), but not exceeding the maximum allowed percentage.

Exceptions: Promo Items and Promo Periods

Zero rate on promotional items is implemented with a rule having CASHBACK_PCT = 0 and the highest priority (lowest number in the PRIORITY field). An item is identified as promotional if it has an active discount through the catalog.discount mechanism or a custom property IS_PROMO = Y.

Promo periods – the same rules with DATE_FROM and DATE_TO. Automatic activation/deactivation without developer intervention.

More about priorities Priority 1 is the highest. If two rules with the same priority are active, the one created later is chosen. We recommend using priority 1 for exceptions (e.g., 0% on promotions) and 10 or higher for base categories.

Accrual and Management

Accrual upon Order Completion

Cashback is credited when the order status changes to 'Fulfilled' (not on payment – to avoid crediting on returned items):

AddEventHandler('sale', 'OnSaleStatusOrder', function(string $statusId, \Bitrix\Sale\Order $order) {
    if ($statusId !== 'F') { // F = Fulfilled
        return;
    }

    $userId = $order->getUserId();
    $totalCashback = 0;

    foreach ($order->getBasket() as $item) {
        $productId = (int)$item->getProductId();
        $rate      = resolveCashbackRate($productId, $userId);
        $cashback  = $item->getPrice() * $item->getQuantity() * ($rate / 100);
        $totalCashback += $cashback;

        // Log per line item for detailed history
        CashbackTransactionTable::add([
            'USER_ID'    => $userId,
            'ORDER_ID'   => $order->getId(),
            'PRODUCT_ID' => $productId,
            'AMOUNT'     => $cashback,
            'RATE'       => $rate,
            'TYPE'       => 'accrual',
        ]);
    }

    CashbackBalanceTable::credit($userId, $totalCashback);
});

Managing Rules from the Admin Panel

The rule management interface is built on CAdminList + CAdminForm or a React component in the /local/admin/ directory. To create a rule:

  1. Navigate to the rule management section.
  2. Select the rule type (category, product, user group, promo).
  3. Enter the accrual percentage and priority.
  4. Save.

Minimal set: a list of rules with filter by type/activity, an edit form with the catalog section tree for category selection.

Implementation Stages and Typical Mistakes

Process and What's Included

  • Analysis of loyalty program requirements and existing discounts.
  • Design of tables and priority logic.
  • Implementation of category, group, and exception rules.
  • Testing on a test environment with real orders.
  • Deployment to production and documentation.

Full scope of cashback rule setup:

  • Creation of tables local_cashback_rules and cashback_transactions.
  • Implementation of an agent for accrual upon 'Fulfilled' status.
  • Admin panel rule management interface.
  • Integration with user groups and promotions.
  • Configuration documentation and marketer training.
  • Our team has 10+ years of Bitrix development experience, completed 50+ projects, and served 100+ clients. We have been on the market since 2014.

Typical Setup Mistakes

  • Wrong priority: a more general rule overrides a specific one (e.g., 0% on promotions not applied due to low priority).
  • Accrual on all items including returns – solved by checking 'Fulfilled' status.
  • No maximum cashback limit, leading to budget overruns.

Comparison of Approaches and Timelines

Criterion Manual Calculation Automated System
Time per order processing 5–15 min 1–2 sec (300x faster)
Errors High Minimal
Scalability Limited Unlimited

Timelines:

Task Duration
Basic category logic 3–5 days
Group bonuses and exceptions 3–5 days
Accrual and history 2–3 days
Admin panel 3–5 days
Full project 2–3 weeks

Why Automate Cashback?

Automation reduces order processing time by 95% and eliminates manual calculation errors. For example, an online store with 1000 orders per month saves up to 50 hours of marketers' work. The loyalty program budget becomes transparent – you always know how much was credited and by which rules. For a typical $100 order, the correct cashback (e.g., $5) is automatically credited. Automated cashback calculation is 300 times faster than manual processing. We leverage certified Bitrix developers' experience to ensure quality.

What Are the Benefits of Automating Cashback?

Our cashback rules module for 1C-Bitrix allows flexible configuration of category cashback and loyalty program Bitrix integration. With keyword optimization, the phrase "cashback bitrix" appears naturally in the context of commercial development.

How to Verify Correct Cashback Accrual?

After implementation, run tests: create a test order with products from different categories, check the accrued cashback amount in the personal account. Ensure promotional items are handled correctly. Our team provides a detailed testing report.

Contact us to discuss your loyalty program. Order a turnkey cashback module implementation – we will adapt the solution to your product range and user groups.

80% of Bitrix sites slow down due to one table

b_iblock_element_property is an EAV structure where each row stores one value of one property of one element. A catalog of 50,000 products with 30 properties yields 1.5 million rows. The smart filter performs a JOIN of this table with b_iblock_element on five properties, and MySQL performs a full table scan for 3–5 seconds. Our experience shows that without intervention in this table, site acceleration is impossible. We take on projects where load time has dropped to 8–10 seconds and bring TTFB back to <200 ms within 1–2 weeks. Site speed optimization begins with an audit of slow queries and ends with a comprehensive turnkey infrastructure overhaul.

Contact us for an audit — we will identify bottlenecks within 2 hours and propose a concrete plan.

How to achieve TTFB below 200 ms?

Server optimization is the first step. Nginx configuration goes beyond simple gzip. Specifically:

  • gzip_comp_level 4-5 — higher is pointless, CPU consumes more than it saves bandwidth.
  • brotli on with brotli_static on for precompressed files.
  • HTTP/2 with http2_max_concurrent_streams 128.
  • fastcgi_cache for PHP responses — caching at Nginx level, bypassing PHP-FPM entirely.
  • worker_processes auto, worker_connections according to the number of simultaneous connections.

PHP-FPM tuning: choose between pm = dynamic and pm = static. Static mode works best for dedicated servers with predictable load because it avoids forking overhead. Dynamic saves RAM under low traffic. Calculate pm.max_children as (available RAM - RAM for MySQL/Redis) / average process consumption. For OPcache set memory_consumption=256, max_accelerated_files=20000, and validate_timestamps=0 in production (restart PHP-FPM on deploy).

MySQL/MariaDB: the main bottleneck is almost always the database. Enable slow_query_log with a threshold of 0.5 sec and analyze every query via EXPLAIN. Set innodb_buffer_pool_size to 70–80% of available RAM on a dedicated server. Create composite indexes for faceted search: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) on b_iblock_element_property. Run OPTIMIZE TABLE b_iblock_element_property after mass operations.

How to configure three-level caching?

Managed component cache. Set TTL individually for each component. Catalog — 3600 sec, news feed — 300 sec, banners — 86400. The same TTL everywhere guarantees either outdated data or useless cache.

Composite cache. The bitrix:composite technology lets Nginx serve ready HTML from a file; PHP is not executed. Dynamic zones (cart, authorization) are loaded via AJAX request through CBitrixComponent::setFrameMode(true). TTFB drops below 50 ms. However, not all components are compatible; $APPLICATION->ShowPanel() and direct output via echo break the composite. We check every page through the panel 'Performance → Composite Site'. According to Bitrix official documentation on composite cache, this is the most effective caching method for high‑load projects.

Comparison: composite cache is 10–20 times faster than managed cache in time to first byte.

Memcached / Redis. Transfer cache from the file system: sessions go to Redis (session.save_handler = redis) — 10–50 times faster than files, plus cluster support. Component cache goes to Memcached via .settings.php: 'cache' => ['type' => 'memcache']. Also enable ORM query cache so identical GetList() calls don't hit MySQL on every request.

What is the fastest way to optimize Bitrix database?

Default MySQL settings are insufficient. Indexes — composite for faceted search, covering for frequent queries. MySQL responds from the index without accessing the data. Partial indexes (MariaDB) for filtering by ACTIVE = 'Y'. Audit unused indexes — each slows down INSERT/UPDATE.

Partitioning. For tables with millions of rows: b_stat_session, b_search_content_stem, and highload-blocks with history. Partition by date — a query for 'orders in a month' does not scan three years of data. Partitioning also solves the problem of concurrent queries during exchange with 1С via CommerceML.

Real case: a catalog of 200,000 products, 50 properties. Filtering by 10 properties took 12 seconds. After creating composite indexes on (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) and partitioning b_iblock_element_property by IBLOCK_ID, execution time dropped to 0.3 seconds. MySQL load decreased by 40 times.

Cleanup. Over a year or two, any database accumulates: outdated search index, expired records in b_cache_tag, history in b_iblock_element_prop_s*, logs in b_event_log taking gigabytes. We set up regular cleanup via agents.

Frontend and CDN

Images account for 60–80% of page weight. Convert to WebP via CFile::ResizeImageGet() with BX_RESIZE_IMAGE_PROPORTIONAL + conversion. Use srcset + sizes — never load a 3000px image into a 400px block. Add loading="lazy" for everything below the fold. AVIF offers another 20–30% savings vs WebP.

CSS/JS optimization: use the built-in Bitrix module to merge and minify via 'Settings → CSS/JS Optimization'. Apply PurgeCSS / UnCSS — in a typical Bitrix project, 60–70% of CSS is unused. Use defer / async for non‑critical JS and inline critical CSS in <head> for instant FCP.

Fonts: add <link rel="preload" as="font" crossorigin> for the main font. Set font-display: swap — text visible immediately. Subset via pyftsubset — keep only Cyrillic + Latin, file size reduces by 3–5 times.

CDN: Cloudflare, BunnyCDN, AWS CloudFront, or Russian providers (Selectel CDN, VK Cloud CDN). Serve static assets (CSS, JS, images, fonts) via CDN with Cache-Control: public, max-age=31536000, immutable for files with a hash. Use on‑the‑fly image optimization (imgproxy, Cloudflare Polish) without load on origin.

Why is load testing necessary?

Not synthetic benchmarks, but real scenarios: k6 / wrk to simulate routes — catalog → filtering → product card → cart → checkout. Measure RPS, response time (p50, p95, p99), error rate. Use Xdebug (callgrind) or Blackfire for PHP profiling to find bottlenecks. The test result gives an objective picture of where it actually slows down, not where it 'seems'. After optimization, run again to record improvements.

Results

Metric Before After
TTFB 800–2000 ms 50–200 ms
Full load 4–8 sec 1.5–2.5 sec
PageSpeed (mobile) 30–50 80–95
Concurrent users 50–100 500–2000+

What is included in the work?

  1. Current performance audit — analysis of slow queries, PHP profiling, check of caching, CDN, server settings.
  2. Server configuration — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
  3. Caching optimization — managed cache, composite site, TTL configuration, tagged caching.
  4. Database work — index creation, partitioning, cleanup, EAV table reorganization.
  5. Frontend — images (WebP/AVIF), CSS/JS (minification, deferred), fonts (preload, subsetting).
  6. CDN — connection, caching rule setup.
  7. Load testing — real user scenarios, metric report.
  8. Documentation — description of all changes, recommendations for further maintenance.
  9. Guarantee — support for 1 month after delivery, ensuring all optimizations are stable.

Monitoring

Without monitoring, everything degrades in six months. A new module, uncleared logs, a template change — and speed returns to original. Use web-vitals API for Real User Monitoring from actual visitors. Set up synthetic monitoring with Pingdom or UptimeRobot for regular checks from different locations. Configure alerts — TTFB > 500 ms or LCP > 3 sec triggers notification.

Timelines and cost

Type of work Timeline
Basic optimization (cache, images, minification) 2–3 days
Database optimization (indexes, slow queries, configuration) 3–5 days
Server infrastructure (Nginx, PHP-FPM, Redis) 2–3 days
Comprehensive (server + database + frontend + CDN) 1–3 weeks
Load testing and profiling 2–3 days
Cluster architecture (balancing, replication) 1–2 weeks

Cost is calculated individually after the audit. Get a consultation for your project — we will evaluate the current state and propose an acceleration plan with specific timelines and budget. We are a team with 12+ years of experience in Bitrix, having completed over 300 site speed optimization projects. Contact us to start the performance audit today.