Why the Bitrix bonus system hits the ceiling of its capabilities
A bonus system built on Bitrix's out-of-the-box mechanism lives comfortably until the first combination of scenarios.
As soon as order-based accrual is combined with customer tiers, point expiration, partner stores, and promotions with overlapping rules, the platform stops answering a simple question — how many points a customer actually has. After that, order is maintained through manual database edits that no one documents.
The first failure point is balance mismatches. The storefront, order page, and marketing report calculate the remaining balance with different queries at different times, and after a return or cancellation, some operations are not rolled back.
The error accumulates quietly: the customer sees one amount, the operator in the admin panel sees another, and reconciliation turns into manually sorting through the transaction history.
The second is parallel orders. Bonus accrual and redemption read the balance before writing the result, so two simultaneous orders pass against the same balance.
The result is a negative balance, double accrual, or a refusal to pay with bonuses for a customer who honestly accumulated them.
The third is manual bonus accruals: compensations, gifts for reviews, agreements with partners.
Such operations have no protection against repeated application and no clear log: a repeated import from a spreadsheet duplicates the balance, and it is already impossible to restore who credited points and why several months ago.
Each failure is fixed point-by-point, but a month later it resurfaces in a new place, because the cause is the same — loyalty rules live in page code, not in a separate accounting loop. We explain how this is closed with out-of-the-box and custom mechanisms.
What an in-house loyalty system delivers: effect in numbers
We calculate the effect of an in-house bonus system not by the number of cards issued, but by the load on infrastructure and the share of operations that run without human involvement. Below are the metrics where the difference is visible immediately.
Operation speed under load
The point balance participates in checkout, so every purchase adds a calculation to the overall flow. Accrual goes into a separate queue, the balance is cached — redemption no longer blocks the cart.
During sale hours, when the order flow grows several times, checkout response time stays at the level of an ordinary day instead of growing with traffic.
Accrual automation
Rules are described by a set of conditions: product category, payment method, customer status, promotion validity period.
The system calculates points, their lifetime, and redemption order itself, so manual balance edits almost disappear — the share of accruals without operator involvement reaches up to 95% of turnover.
Eliminated class of failures
Double accrual for a repeated click, balance mismatch after a return, an order stuck on an error in a promo code — these are typical failures when loyalty logic lives in template edits.
The balance movement log and protection against repeated operations eliminate this class entirely: every record shows where the point came from.
Promotion support without modifications
We launch a new promotion by configuration, not by code changes: conditions, periods, segments, and limits are set in the interface. Marketing stops waiting for development, and changes do not break already working rules.
Custom module on Bitrix or external service: comparison of approaches
The choice comes down to three scenarios: stay with the platform's out-of-the-box tools, write a custom module on top of the core, or move accruals to an external service.
All three answer one question — where the balance is stored, who calculates the rules, and what happens when program conditions change on the fly. Comparing them by capabilities is pointless; the difference shows up in limitations and in the amount of maintenance.
| Option | When it fits | Solution limitations |
|---|---|---|
| Out-of-the-box loyalty module | Simple scheme: bonus for registration, cumulative percentage, one-time promotions | Rules are set by the platform; tiers, point lifetimes, and segmentation will require workarounds |
| Custom module on the core | Your own accrual rules, integration with orders, inventory, and accounting in 1C | Maintenance is entirely on you: platform updates, conflicts with other modules, fault tolerance of accruals |
| External loyalty service | Multiple sales channels, offline points, a single balance outside the website | Logic outside your loop, synchronization delays, dependence on the provider's terms |
| Hybrid: website plus external service | Online orders and offline sales, end-to-end analytics across all points needed | Dual support loop and a mandatory balance reconciliation procedure |
Out-of-the-box tools are enough while rules fit ready-made templates.
As soon as tiers, different conditions for customer segments, or integration with an accounting system appear, workarounds begin to pile up, and supporting them costs more than loyalty logic designed from the start.
A separate risk area is data reconciliation: in an external service, you need to match balances after a communication failure and canceled orders, while in your own module, you need to maintain correctness during simultaneous orders from the same customer.
Below we explain how to choose the option for the process so that you do not build in a limitation at the start.
Stages of loyalty system development: from audit to launch
The work is structured so that loyalty rules are described and verified before the first line of code.
An error in the accrual formula on a live website costs more than a week of design: points have already been spent by customers, and receipts cannot be recalculated retroactively.
-
Audit of accrual rules. We consolidate current promotions, tiers, exceptions, and manual adjustments into an "event → condition → result" table.
This is where conflicts surface: a discount and a bonus are calculated from the same amount, personal conditions argue with general ones.
-
Bonus calculation scheme. We fix the accrual base, rounding, point lifetime, discount priority over bonus, redemption limit from the order total, and behavior on return. Then, according to this specification, code is written and checks are built.
-
Data design. We decide where the balance lives — in the accounting system or on the website — and how balances and transaction history are synchronized. A repeated request during a communication failure must not accrue points twice.
-
Implementation on 1C-Bitrix. We connect cart and checkout events, registers, deferred tier recalculation, and customer notifications. Manual accruals and disputed operation review appear in the administrative section.
-
Testing on orders. We run through real history: an order with several promotions, partial cancellation, return after points redemption, purchase at a tier boundary. The balance after each step is compared with the reference.
-
Handover and launch. We provide documentation, a regulation for managers, and access to operation logs. For the first weeks, we review the accrual and redemption report to catch a mismatch immediately.
What we hand over to the client: configurations, schemes, regulations
We deliver a project on 1C-Bitrix not only as working code: bonus system rules live in configuration, not in the developer's head. Below is a set of artifacts your team can use to change promotion conditions and investigate incidents without reading source code.
- Settings for accrual and redemption rules — tiers, bonus lifetimes, point payment limits, rounding, and discount priority are set by parameters, not code edits.
- Data exchange scheme — which events go to the accounting system, which come back, where the balance reconciliation point is, and how a customer mismatch is handled.
- Access policies — separation of roles for marketer, manager, and administrator: who changes conditions, who sees reports, who confirms manual accruals and redemptions.
- Loyalty documentation — description of tiers, accrual formulas, exceptions, system behavior on product return and order cancellation.
- Promotion regulation — a list of steps for launch and stop: dates, rollback points, procedure for notifying participants and summarizing results.
- Support regulation — which requests are closed by planned work, which are considered urgent, and how an exchange incident is handed over.
- Operation log and exports — where to view a customer's accrual history and how to export it for reconciliation with accounting.
The package removes dependence on the solution's author: your marketer changes promotion conditions, and an engineer gets involved only when it concerns exchange and data integrity.
Case study: rebuilding bonus accrual in a retail store
What it was
A store with several locations ran a bonus program on custom modules: accrual and redemption were calculated separately from the order and transferred to accounting manually.
The cashier closed the shift and reconciled card balances in a spreadsheet — a mismatch of a couple of entries surfaced the next day, and the cause was lost among edits.
Up to a third of operations went through manual accrual, disputed balances went to support by email, and resolving one card took a day.
What was changed and what was achieved
Bonus calculation moved into 1C-Bitrix core transactions: accrual and redemption are performed in one operation with the order, so the balance is not lost between steps.
Each operation received an idempotent key — a repeated call does not create a duplicate, and a mismatch is visible by the link to the source order. Balance reconciliation now runs on a schedule and catches mismatches before the shift opens, not after a customer complaint.
Metrics before and after: the share of manual accruals fell to tenths of a percent — edits remained only for promotions. Support requests about bonuses became approximately five times fewer; the operator answers from the log, without exports and recalculations.
Closing a shift takes minutes instead of half an hour, and reconciliation finishes before the location opens.
What to do if loyalty is already deployed on another platform?
Migrating loyalty is not migrating a table of points. A participant's balance is derived from the history of accruals and redemptions, and if you pull only the final numbers, the first disputed request runs into the absence of an operation basis.
Therefore, we start migration to 1C-Bitrix with a revision: we export the operation log for the required depth, map the old platform's accrual types to the new bonus system's rules, and separately mark exceptions — manual adjustments, gift points, expired balances.
Migration of balances goes as a separate "incoming balance" operation with a start date, not as a recalculation of the entire history: otherwise old expiration rules and redemption multiples will distort reports and tier thresholds.
The history is preserved as a reference layer — support needs it when a customer disputes a redemption.
Next, we choose the inclusion scheme. Parallel operation of the loops: the new system calculates accruals in shadow mode, the old one continues serving live operations, and we compare control sums for each participant per day.
The mismatch must be zero — if there is one, we correct the rule mapping before switching, not after.
We phase out the old platform gradually: first transferring writes to the new loop, then only reading from the old one — with a window that covers the point expiration period and the claims period.
This way, decommissioning does not cut off requests, and the archive layer remains available until the last disputed period closes.
Technical concerns: load, integrations, data migration
Before launching a loyalty program on a 1C-Bitrix storefront, engineers check the same things: whether bonus calculation can withstand peak load, how exchange with the accounting system works, what happens on order cancellation, and whether data integrity is preserved when transferring accumulated points.
How does bonus calculation behave under peak load?
We move accrual and redemption out of the synchronous checkout path: the operation goes into a queue, the balance is recalculated in the background, and the customer is shown the confirmed value.
At acceptance, we show measurements — how many simultaneous checkouts the cart handles with bonus calculation enabled and how quickly the balance updates.
How is exchange with the accounting loop arranged and what happens when it is unavailable?
Exchange goes in portions by change log, not as a full export: each operation receives an identifier, so repeated delivery does not create a duplicate accrual. If the accounting system does not respond, changes accumulate in a queue and arrive after recovery.
What happens on order cancellation or return?
Cancellation is a separate operation with a reversing entry: accrued bonuses are reversed, redeemed ones are returned to the account.
If the customer has already spent the points, the system records a negative balance or blocks part of the accruals according to a rule agreed in advance.
How are accumulated points transferred without losing history?
We transfer balances and operation history with reconciliation: the number of accounts, amounts, and dates of the latest accruals are compared before and after migration; mismatches go into a report.
Until reconciliation matches, the old loop remains available read-only — rollback is possible at any stage.
Let's discuss the task: we'll analyze the rules and come back with a plan
So that the estimate of work relies on facts, not on an "from and to" range, we start with an analysis of loyalty rules: how points are accrued and redeemed, whether there are tiers and expiration periods, category restrictions, how bonuses combine with discounts and promos.
These rules define the data scheme, not the other way around — so first a conversation about logic, then about timelines.
- We get acquainted with the rules and processes: how points are accrued now, where accounting is kept, what is already failing.
- We look at what is configured in the system and how exchange with the accounting system works, so as not to duplicate ready-made mechanisms.
- We determine where the balance is calculated: in the order, by a separate module, or on the 1C side — this affects reconciliation with accounting and response speed.
- We analyze edge cases: return, cancellation, partial payment, repeated accrual — for each, we fix the expected behavior.
- We agree on integrations: nomenclature, counterparties, payments, mailings — for each channel, we determine the format and frequency of exchange.
- Work estimate: we divide the task into stages, state timelines and risks, and show what can be released earlier.
- Implementation plan: order of release to the production loop, transfer of accumulated points, rollback on error.
- Team composition: developer, integration engineer, tester, and a client representative who makes decisions on rules.
If some items are already solved for you or the rules are still being discussed — tell us, and the estimate will be more precise. Describe the task — we will come back with an implementation plan, team composition, and timelines by stage.