Development of a Product Subscription Module for 1C-Bitrix

1C-Bitrix subscription module: where the repeat sales logic breaks

A product subscription breaks not on the storefront, but at the moment when a recurring order has to turn into an actual shipment.

A typical failure: the warehouse has written off a unit against a regular sale, while the scheduled write-off for the subscription went into the queue with the previous stock balance — and the client gets a rejection after confirmation.

Then the chain snaps: the repeat order hangs in an undefined status, support manually reconciles the movements, and some subscribers quietly drop off.

The second class of problems is duplicates. The scheduler and an external trigger fire on the same date, and the 1C-Bitrix subscription module creates two orders for one buyer.

If the mechanics lack idempotency by subscription key and period, duplicates accumulate unnoticed: stock balances diverge, write-offs get doubled, and reconciliation with 1C shows a discrepancy in the item nomenclature.

The third failure is the loss of statuses during deferred write-offs. The order goes into awaiting payment, the payment arrives later, and the handler has already cleared the subscription's active flag.

As a result, stock and status synchronization runs out of step: the item is reserved, but the subscription is listed as inactive. Let's break down how this is closed at the logic level, rather than with crutches in the handlers.

What a properly designed subscription delivers

A properly designed subscription is not a "checkbox" in a product card, but a separate business process that lives in the core and initiates repeat sales on its own.

When the mechanics are built into the platform rather than assembled from external scripts, recurring orders are generated on schedule, not by a customer's phone call. The share of repeat orders no longer depends on whether a manager remembered to call.

Order automation removes the manual operations that typically eat into margin: stock reconciliation, price recalculation, limit checks, and sending notifications.

The customer receives delivery on their own interval, the system gets a predictable load, and managers focus on new deals instead of the routine of reissuing invoices.

Customer retention grows not through discounts, but because the right product arrives on time and without reminders.

A separate effect is the eliminated class of billing errors. When payment, reservation, and shipment go through a single scenario, double charges, "stuck" subscriptions, and discrepancies between warehouse and orders disappear.

This is not cosmetic: each such error means a refund, manual investigation, and lost customer trust.

We design subscriptions so they can be extended: flexible intervals, pause and resume, item replacement, and different terms for different customer groups.

The logic lives in the core and is reused in the customer portal, the admin panel, and external integrations — without code duplication or "crutches" at every step.

Comparison of approaches: built-in mechanism, customization, standalone module

The choice between a built-in mechanism, core customization, and a standalone module is a choice between launch speed and maintenance cost.

Built-in tools cover the basic scenario, but as soon as rules for products, inventory stock, and roles appear, the boundaries become noticeable. Below are three options with the real limitations of each.

Why core customization is the most expensive path

Core edits work fast at the start, but every platform update turns into a revision: you need to compare modified files, migrate the logic, and check that related scenarios haven't broken. The more edits there are, the higher the support cost — it grows non-linearly.

Where a standalone module wins

A module isolates subscription logic: accrual rules, recurring charges, and the link with 1C and inventory stock all live in one place. A platform update doesn't break the module, and the module itself is versioned separately.

This is more expensive at the design stage, but cheaper in maintenance when there is more than one scenario.

We analyze your scenario and propose an option suited to the load — without unnecessary customization where the built-in mechanism is enough.

How we design and implement a subscription module

Designing a subscription module starts not with code, but with an audit of the logic: we look at how orders, inventory stock, user-to-deal binding, and the schedule of recurring operations are already set up in the system.

At this stage, it is important to find hidden dependencies — for example, stock being deducted at the moment an order is placed rather than at payment — otherwise automatic repeats will start breaking the records.

Based on the audit results, we lock down the data schema and integration points with 1С so that the subscription does not duplicate existing entities.

Then the work proceeds in stages, each ending with a verifiable result:

1. Audit of the current logic of orders, stock, and access rights — a dependency map and a list of bottlenecks.
2. Module design: subscription storage schema, trigger rules, pause and cancellation scenarios.
3. Agreeing on behavior with the client: what happens on non-payment, out-of-stock, or address change.
4. Development with the logic isolated in a separate module — core updates do not overwrite the customization.
5. Testing: running recurring charges, handling payment failures, correctness of stock and notifications.
6. Handover: setup documentation, employee training, walkthrough of typical failures.

Separately, we check behavior under load — how the scheduler behaves when subscriptions reach thousands and charges come in waves. Testing includes failure scenarios: payment did not go through, the item ran out, the user changed the payment method. For each case, predictable behavior is built in, rather than a silent error in the logs.

After handover, the client's team can change subscription terms and add products without a developer. If the logic becomes more complex, we remain on support — but basic configuration does not require constant involvement of engineers.

What the client receives upon handover after implementation

Handover is not "access to the server and a couple of messages in a messenger." We deliver a complete package that your team or another contractor can use to develop the 1C-Bitrix subscription module without us: configurations, schemas, operational procedures, and documentation in one place.

• Module configurations — settings for subscription types, billing frequency, warehouse binding, and price recalculation rules, moved into files rather than core modifications.
• Data and relationship schemas — how the module interfaces with the catalog, cart, orders, and 1C exchange: which entities it reads, which it creates, and where the extension points are.
• Access policies — roles and permissions for administrators, managers, and external integrations: who manages subscriptions, who sees billing history, and who is denied access to payment data.
• Operational procedures — how to start and stop subscriptions, handling failed charges, retries, customer notifications, and rules for manual intervention.
• Exchange documentation — formats and schedules for synchronization with 1C, behavior when stock levels diverge, and what to do when the connection is lost.
• Deployment instructions — the sequence for installing on the test and production environments, dependencies, and rollback points to the previous version.
• Changelog and development roadmap — what has already been completed, which scenarios were deliberately left for the next stage, and why.

We discuss the handover separately: we conduct a walkthrough with your engineer, answer questions about the schemas and procedures, and establish who is responsible for each environment.

After that, the module operates autonomously in your infrastructure — with no mandatory dependency on us.

Case study: how product subscriptions cut manual operations by two-thirds

The client is a wholesale supplier of consumables with a catalog of several thousand SKUs. Orders came in manually: a manager checked stock, issued an invoice, and reminded about reordering using their own spreadsheet.

At peak, this produced up to a hundred manual operations a day, and some regular customers churned simply because they were forgotten in time.

We built a product subscription module on 1C-Bitrix: the buyer sets the frequency and contents of the cart, the system generates the repeat order itself, checks stock via exchange with 1C, and sends an invoice.

If an item is out of stock, the order doesn't fail silently — it goes into a queue with a notification to the manager, and the client receives a replacement offer.

What changed after implementation

We separately closed a class of failures that used to hit revenue: orders for out-of-stock items. Now the subscription checks against current 1C stock before generating, not after.

The exchange logic is built on the platform's standard mechanisms, so core and module updates don't break the scenario.

1C-Bitrix in this project is not only a catalog but also the integration point with the accounting system: order statuses, reserves, and prices are pulled from 1C, and the subscription works on top of ready-made entities.

Six months after launch, the share of repeat orders more than doubled, and the load on managers dropped so much that the same team size began handling twice as many active clients without new hires or overtime.

How is a product subscription different from a regular auto-order?

A subscription and a regular auto-order solve different problems, although they look similar on the surface: in both cases, the customer receives the product again without manual checkout.

The difference lies in who controls the frequency and what happens when the product is out of stock.

An auto-order is a rigid calendar. The client sets an interval (once a week, once a month), the system generates an order on schedule from a fixed list and deducts the remaining balance.

If an item is out of stock, the order either goes out partially or fails entirely — depending on the configured policy. Inventory management here is reactive: the warehouse does not influence when the next request comes in; it only answers "yes" or "no."

A subscription is built around product availability, not around a date.

The frequency is the desired rhythm, but the actual deduction is tied to arrival at the warehouse: the item appears — the order is assembled and shipped; the item is in deficit — the subscription goes into a waiting state and does not break.

The customer does not receive partial shipments and does not lose their settings due to a temporary product absence.

This leads to different inventory management requirements. For an auto-order, reserving at the moment the request is generated is sufficient.

For a subscription, pending obligations need to be tracked: the system maintains a queue of subscribers for each item and, upon arrival, allocates the volume to it.

This also changes the notification logic — with an auto-order, the customer learns about a cancellation after the fact; with a subscription, they receive a waiting status in advance.

In practice, both mechanisms often coexist: an auto-order covers consumables with predictable demand, a subscription covers products with fluctuating availability.

The choice is determined by what is more critical for the business: a strict delivery rhythm or the absence of disruptions during a deficit.

Common technical concerns before starting

Before starting, the same engineering questions almost always come up: how the module will get along with the current core, whether it will handle the load, whether it will break the exchange with 1C, and what will happen during updates. Below are substantive answers, without marketing.

Load: what will happen during peak activity?

Subscriptions are background tasks: recalculating availability, notifications, stock synchronization. We move them into a deferred queue and agents with limited concurrency so that a spike in orders does not block the storefront.

Heavy queries are covered by indexes and caching, and periodic operations are spread across a schedule. At peak, the catalog and checkout remain responsive — only the speed of background notifications degrades, and even then predictably.

Integration with 1C: will the exchange break?

A subscription relies on the same entities as a regular order, so the exchange follows standard scenarios: nomenclature, stock, prices, statuses. We pass additional subscription fields in agreed-upon attributes without breaking the existing export.

If the exchange is already working, we extend it rather than building a second channel, otherwise we get stock desynchronization and double write-offs.

Updates: will customizations fall off?

We keep the logic in the module and template, not in the core, so updates of the platform and third-party solutions proceed as standard. Before each update, we run a regression across subscription scenarios: checkout, renewal, cancellation, notifications, exchange with 1C.

We record changes in the repository with descriptions so that rolling back to a previous version takes minutes, not hours of searching for the cause.

If you still have concerns about your stack, describe the task and we will get back to you with an estimate and a work plan.

Let's discuss your subscription module task

To make the subscription module estimate realistic rather than an "industry average," we need the context of your project: how the catalog, warehouses, and checkout are currently set up, and which subscription scenarios are critical. Then we'll analyze the task and come back with a work plan and timelines by stage.

What we clarify at the start

• Subscription model: regular delivery of a single product, a set with a fixed composition, or free choice within a limit.
• Frequency and rules: fixed interval, calendar dates, pause, skipped delivery, item replacement.
• Behavior when a product is out of stock: wait for restock, replace with an analog, or notify the customer.
• Payment: one-time payment per cycle, saved card, invoice for legal entities, auto-renewal, and handling failed charges.
• Integration with 1C: exchange of orders, stock, and subscription statuses, export rules, and synchronization frequency.
• Customer account: managing the subscription, delivery history, changing the address and payment method.

What to send for the estimate

• Access to a test environment or a copy of the site and a description of the current catalog structure.
• The exchange scheme with 1C: which entities are already synchronized and which need to be added.
• A list of business rules for subscriptions — even as a table or notes.
• Examples of emails and notifications that should go to the customer at each step.

How we structure the work

• We analyze the task and document the subscription scenarios in a short description.
• We check against the current site architecture and the 1C exchange, and mark the points that need rework.
• We prepare a work plan: stages, dependencies, and what we do first.
• We agree on the plan and acceptance criteria for each scenario.
• We implement the module, connect payment and notifications, and test it in the staging environment.
• We deploy to production and hand over instructions to your team.

Describe the task in free form — we'll come back with an estimate, a work plan, and a clear next step.