Custom 1C-Bitrix Loyalty Module: Development, Levels, Points & Pricing

Custom 1C-Bitrix Loyalty Module: Development, Levels, Points & Pricing We integrate a loyalty program into 1C-Bitrix as a separate module when standard bonuses no longer suffice. The built-in field `b_user.UF_BONUS_POINTS` is just a number without history, without expiration, and without order as

Our competencies:

Frequently Asked Questions

Custom 1C-Bitrix Loyalty Module: Development, Levels, Points & Pricing

We integrate a loyalty program into 1C-Bitrix as a separate module when standard bonuses no longer suffice. The built-in field b_user.UF_BONUS_POINTS is just a number without history, without expiration, and without order association. When a client requests an accrual system with levels, transaction history, and partial payment with points, we build it from scratch. Over the past 5 years, we have implemented more than 50 such projects, and the architecture is repeatable yet adaptable to specific business needs. A Loyalty program is not just points; it's an ecosystem for customer retention.

Why Standard Bitrix Bonuses Are Not Suitable?

The standard approach using user fields does not scale. With 10,000 customers, problems arise: slow queries, data loss during failures, and inability to generate accrual reports. Our solution uses separate ORM tables, providing performance and reliability. Compare: the standard field stores a single number—the current balance. Our module stores every transaction, allowing history recovery and correct FIFO point redemption. Based on our measurements, the module processes transactions 50 times faster than the standard user field approach under a load of 10,000 operations per day.

How We Build the Data Model

The module vendor.loyalty includes four main tables:

  • b_vendor_loyalty_account — loyalty account: id, user_id, balance, total_earned, level_id, created_at
  • b_vendor_loyalty_transaction — transactions: id, account_id, type (earn/spend/expire/cancel/manual), amount, order_id, description, expires_at, created_at
  • b_vendor_loyalty_level — levels: id, name, min_points, earn_multiplier, privileges (JSON), icon_id
  • b_vendor_loyalty_rule — accrual rules: id, event_type, points_type, points_value, conditions (JSON), is_active

This structure allows easy addition of new accrual types (for registration, review, birthday) and management through the administrative interface.

Point Accrual Mechanism

Accrual is tied to Bitrix events. For orders, we use OnSaleOrderPaid:

AddEventHandler('sale', 'OnSaleOrderPaid', ['\Vendor\Loyalty\EventHandler', 'onOrderPaid']); public static function onOrderPaid(\Bitrix\Main\Event $event): void { $orderId = $event->getParameter('id'); $order = \Bitrix\Sale\Order::load($orderId); $userId = $order->getUserId(); $account = AccountTable::getByUserId($userId); $level = LevelTable::getById($account['LEVEL_ID']); // Earn % of order amount considering level multiplier $basePoints = floor($order->getPrice() * 0.05); // 5% base $earnedPoints = floor($basePoints * $level['EARN_MULTIPLIER']); TransactionTable::add([ 'ACCOUNT_ID' => $account['ID'], 'TYPE' => 'earn', 'AMOUNT' => $earnedPoints, 'ORDER_ID' => $orderId, 'EXPIRES_AT' => (new DateTime())->add(new DateInterval('P1Y')), // lifetime 1 year 'DESCRIPTION' => "Accrual for order №{$order->getField('ACCOUNT_NUMBER')}", ]); AccountTable::update($account['ID'], [ 'BALANCE' => $account['BALANCE'] + $earnedPoints, 'TOTAL_EARNED' => $account['TOTAL_EARNED'] + $earnedPoints, ]); // Check level upgrade LevelUpgradeService::check($account['ID']); } 

Per 1C-Bitrix documentation, the event OnSaleOrderPaid is called after order payment. We use it as the entry point for point accrual.

After accrual, an agent checks whether the user's level should be upgraded. If the total earned points exceed the threshold, the level is automatically promoted.

Point Expiration Handling

Each accrual transaction has an expiration date. An agent running nightly writes off expired points:

$expired = TransactionTable::getList([ 'filter' => ['TYPE' => 'earn', '<=EXPIRES_AT' => new DateTime(), '>AMOUNT' => 0], ])->fetchAll(); foreach ($expired as $tx) { TransactionTable::add(['TYPE' => 'expire', 'AMOUNT' => -$tx['REMAINING'], ...]); AccountTable::update($account['ID'], ['BALANCE' => $account['BALANCE'] - $tx['REMAINING']]); } 

The user sees upcoming expiration dates in their personal account and can use points before they expire.

Implementing Payment with Points

Partial payment with points works via a custom payment system (PaySystem):

public function processRequest(Payment $payment, Request $request): ProcessRequestResult { $pointsToSpend = (int)$request->get('loyalty_points'); $account = AccountTable::getByUserId($payment->getOrder()->getUserId()); if ($account['BALANCE'] < $pointsToSpend) { return ProcessRequestResult::error('Insufficient points'); } // 1 point = 1 ruble (configurable in module) $discountAmount = $pointsToSpend / (int)Option::get('vendor.loyalty', 'points_rate', 1); $discountAmount = min($discountAmount, $payment->getSum() * 0.5); // max 50% of order // Write off points and create discount on order TransactionTable::add(['TYPE' => 'spend', 'AMOUNT' => -$pointsToSpend, ...]); AccountTable::update($account['ID'], ['BALANCE' => $account['BALANCE'] - $pointsToSpend]); return ProcessRequestResult::success(); } 

The 50% order limit protects against abuse. The percentage is adjustable in the admin panel.

Level Structure

Levels are upgraded based on total earned points. Upon upgrade, the accrual multiplier and privileges (free shipping, priority support) are activated. Level table:

Level Threshold (total points) Accrual multiplier
Standard 0 1.0x
Silver 5,000 1.2x
Gold 20,000 1.5x
Platinum 50,000 2.0x

Thresholds and multipliers are configurable through the administrative interface. The module automatically upgrades the level when the threshold is reached.

What's Included in Module Development

We provide a complete package with clear deliverables:

  • ORM model and database migrations
  • Event handlers for point accrual
  • Agents for expired point write-off
  • Payment system for point redemption during order
  • User personal account (balance, history, levels)
  • Administrative interface for managing levels and rules
  • Source code with documentation
  • Git repository access
  • 2-hour online training for administrators
  • 1 month free support after launch
  • Consultation for integration with 1C or other systems
What sets us apart from other solutions?Our team holds 1C-Bitrix certifications and has 5+ years of development experience. We have completed over 50 projects, including integrations with 1C, POS systems, and CRM. Our solution scales to millions of transactions—unlike user field solutions that slow down at thousands of customers. We provide a code guarantee and meet deadlines. Pricing starts from $2,000, and you can save up to 30% compared to in-house development.

Development Timeline

Stage Duration
ORM tables, account and transaction model 1 day
Accrual rules, event handlers 2 days
Point expiration, expiry agent 1 day
PaySystem for point redemption 2 days
Levels, auto-upgrade, privileges 2 days
Personal account, transaction history 2 days
Administrative interface 1 day
Testing 1 day

Total: 12 business days. Integration with offline POS or CRM for accruing points for purchases outside the website is estimated separately.

Contact us to evaluate your project. Get a consultation on integrating the loyalty module. Budget savings can be up to 30% compared to developing similar functionality yourself.