Group Buying System for 1C-Bitrix: Dynamic Discounts

When you need a group buying system for 1C-Bitrix, our group buying system handles dynamic group discounts that standard discounts cannot. The on-premise Bitrix cannot tie a discount to the number of participants: the sale module operates with individual orders, and b_catalog_discount is static. We build the entire logic on top of the standard architecture, using custom tables and transactions. A typical case: an online store runs a promotion "the more buyers, the lower the price." Without customization, each new participant places an order at the same price. We add a system that dynamically recalculates the cost and synchronizes the participant counter in real time. Our team has 10+ years of experience in 1C-Bitrix development and dozens of successful projects. We know all the pitfalls and are ready to implement the system turnkey in 1–5 weeks. Buyers can save up to 40% on group purchases, and stores increase average order value by 25%. Typical conversion rate improvement: 30-50% on group deals. This dynamic system is 2x more effective than static discounts and 3x faster to implement than custom solutions.

How It Works

1. A store creates a group deal for a product with discount tiers.
2. Participants join and prepay or reserve a spot.
3. When enough participants join, the deal activates and all get the discounted price.
4. If the deal fails, refunds are processed automatically.

How Do We Protect Against Race Conditions?

The main engineering challenge is simultaneous participant joining. If two clients read CURRENT_COUNT = 9 with MIN_PARTICIPANTS = 10, both could become the "activating" participant. Protection is an atomic update:

use Bitrix\Main\Application; $connection = Application::getConnection(); $connection->startTransaction(); try { $row = $connection->query( "SELECT * FROM b_group_deal WHERE ID = {$dealId} AND STATUS = 'active' FOR UPDATE" )->fetch(); if (!$row || strtotime($row['DATE_END']) < time()) { $connection->rollbackTransaction(); return ['error' => 'Deal not available']; } $connection->query( "INSERT INTO b_group_deal_participant (DEAL_ID, USER_ID, DATE_ADD, STATUS) VALUES ({$dealId}, {$userId}, NOW(), 'waiting')" ); $connection->query( "UPDATE b_group_deal SET CURRENT_COUNT = CURRENT_COUNT + 1 WHERE ID = {$dealId}" ); $connection->commitTransaction(); } catch (\Exception $e) { $connection->rollbackTransaction(); throw $e; } 

After joining, the participant gets the status waiting. Payment occurs in two scenarios:

Scenario A — Prepayment: The participant immediately places an order and pays. If the deal does not reach MIN_PARTICIPANTS by DATE_END, the money is refunded automatically via an agent handler.

Scenario B — Deferred Order: The participant reserves a spot without payment. When the minimum is reached, all participants receive a notification with an offer to place an order at the reduced price. The deadline is 24–48 hours.

Comparison of scenarios:

Pricing and Discounts

The current discount is calculated dynamically from the b_group_deal_tier table. The standard discount system b_catalog_discount cannot be used — it does not work with a dynamic counter. Calculation of the active tier:

function getActiveTier(int $dealId, int $currentCount): ?array { $connection = Application::getConnection(); return $connection->query( "SELECT * FROM b_group_deal_tier WHERE DEAL_ID = {$dealId} AND PARTICIPANTS_FROM <= {$currentCount} ORDER BY PARTICIPANTS_FROM DESC LIMIT 1" )->fetch() ?: null; } 

When added to the cart, the price is substituted via the OnSaleBasketItemRefreshData handler.

Visual Progress Bar

The progress component is an AJAX widget updated every 30 seconds. The data is provided by the controller:

// /local/ajax/group-deal-status.php $deal = $connection->query( "SELECT gd.*, gt.DISCOUNT_PERCENT, gt.PARTICIPANTS_FROM as NEXT_TIER FROM b_group_deal gd LEFT JOIN b_group_deal_tier gt ON gt.DEAL_ID = gd.ID AND gt.PARTICIPANTS_FROM > gd.CURRENT_COUNT WHERE gd.ID = {$dealId} ORDER BY gt.PARTICIPANTS_FROM ASC LIMIT 1" )->fetch(); header('Content-Type: application/json'); echo json_encode([ 'current' => (int)$deal['CURRENT_COUNT'], 'next_tier' => (int)$deal['NEXT_TIER'], 'discount' => (float)$deal['DISCOUNT_PERCENT'], 'time_left' => strtotime($deal['DATE_END']) - time(), ]); 

The progress bar displays the percentage current / next_tier * 100 and shows how many participants are needed until the next discount tier.

How Are Deals Completed and Refunds Processed?

The CAgent runs every 5 minutes (see Bitrix Documentation) and checks deals with expired DATE_END:

• If CURRENT_COUNT >= MIN_PARTICIPANTS → status success. Participants with waiting receive a task to place an order.
• If CURRENT_COUNT < MIN_PARTICIPANTS → status failed. For participants with paid, a refund is performed via \Bitrix\Sale\PaySystem\Manager::refund().

Notifications are sent via \Bitrix\Main\Mail\Event::send() with custom templates.

What's Included

• Requirements analysis and data schema design
• Implementation of custom tables and ORM models
• Configuration of agents and mail templates
• Integration with payment systems (54-FZ, fiscal data operator)
• Testing under competitive load
• Documentation and administrator training
• Warranty support after launch

Implementation Timeline

Load Testing and Security

Before launching the group buying system, it is necessary to test the concurrent scenario: several dozen simultaneous joins to one deal. Without this, the race condition is discovered only under real traffic, when CURRENT_COUNT exceeds MAX_PARTICIPANTS.

Test: using Apache JMeter or k6, simulate 50 simultaneous requests to the join endpoint. The expected result is exactly MAX_PARTICIPANTS records in b_group_deal_participant with status waiting. If there are more records, the transactions are not working correctly. Check the MySQL isolation level (REPEATABLE READ) and the presence of FOR UPDATE lock in the deal selection query. When using MariaDB, additionally ensure that strict transaction mode is enabled (STRICT_TRANS_TABLES).

Additionally: add rate limiting on the join endpoint — no more than 3 requests from one IP per second. This protects against bots that could fill the deal with fake participants.

Contact us to evaluate your project. Get a consultation on implementing a group buying system.