Custom Bitrix checkout: where the standard scenario breaks
The standard checkout scenario in 1C-Bitrix is designed for a simple cart: one item — one price, stock is deducted synchronously, payment goes through immediately after confirmation.
As soon as trade offers appear in the catalog, reserves across multiple warehouses, discounts that depend on the cart composition, or installment payments, desynchronization begins.
The cart shows one quantity, the warehouse reserves another, and when recalculating after changing the delivery method, some items silently disappear from the order — the customer sees an empty line instead of a product and leaves.
The most expensive checkout error is losing items during recalculation.
The standard handler rebuilds the cart on every change of conditions, and if a custom product, a gift item, or a made-to-order product is not described in the recalculation rules, it drops out of the order without an error in the log.
The order goes to the warehouse incomplete, the customer receives something other than what they paid for, and the manager finds out about it from a phone call.
The second common point of failure is the payment step: the payment system returns a status that the module does not map to the internal order status, and the buyer hangs on the waiting page even though the money has already been charged.
The third failure is desynchronization between the cart and the warehouse during parallel orders.
Two customers simultaneously check out the last unit, the reserve is placed for both, but the deduction goes through for only one — the second order fails with an error after payment. The standard reservation logic is not designed for such scenarios without modification.
We analyze each of these failures on a specific project: we look at exactly where the item is lost, how the cart behaves during recalculation, and what happens at the payment step.
Then we describe the logic of custom checkout for your catalog and sales rules — with explicit handling of reserves, idempotent payment confirmation, and logging of every cart change, so that loss of items is visible immediately, not at the warehouse.
What a reworked checkout delivers
A reworked checkout is not a change to the look of the form, but a replacement of the logic by which the cart is completed.
The standard 1C-Bitrix template walks the buyer through a fixed chain of steps and requires registration before payment; if there is no need for it, every extra screen is a point where some people leave.
A custom checkout on Bitrix rebuilds the route around the real purchasing scenario: fields are pulled from the profile, the address and delivery method are filled in based on geolocation or a previous order, and payment is available immediately after the order contents are confirmed.
The first measurable effect is checkout speed.
When a buyer goes through the cart in one screen instead of three or four, the time to payment is cut several times over, and the share of abandoned carts drops: the main reason for drop-off is not "changed my mind," but accumulated fatigue from steps, re-entering data, and mandatory registration. We remove precisely these points, rather than "simplifying the design."
The second effect is the class of payment failures. The payment gateway, the delivery service, and the warehouse respond asynchronously, and if one of them fails, the order must not "hang" in an undefined status.
Cart and order event handlers record the result of each step, retry the failed request, and show the buyer a clear state instead of a technical error — cart conversion stops depending on one-off integration failures.
The third effect is manageability.
The logic of the steps, the set of fields, the free-delivery conditions, and the discount rules are moved into settings rather than into the template code: marketing changes the checkout scenario without a release, and the team does not spend a cycle editing the markup for every promotion. Below we break down how this is structured and what is needed from your team.
Approaches to Building Custom Checkout
The choice of approach determines not only the launch timeline, but also how predictably the checkout will survive platform updates and growing load.
The standard component, a custom module, and an external service solve the same problem with different tools — and diverge in support cost over the long run.
| Option | When it fits | Limitations |
|---|---|---|
| Customizing the standard component | Logic is close to typical: custom fields, steps, hints, delivery calculation | Changes to the template and handlers get overwritten on update unless moved to a separate layer |
| Custom checkout module | Non-typical logic: step-by-step scenario, multiple carts, approval, custom discount rules | Takes longer to start, requires designing the data schema and migrations |
| External checkout service | A separate interface is needed, high load, integration with external systems | Two sources of truth for orders, synchronization of statuses and stock, a separate access perimeter |
Customizing the standard component delivers the fastest result when the purchase scenario doesn't change fundamentally. We move custom logic into a separate layer on top of the standard one — so updating the core doesn't break the checkout, and changes remain manageable.
A custom module is justified when order rules become part of the business model: multiple warehouses, deferred payment, request approval. What matters here is the data schema and migrations — otherwise transferring orders between versions turns into manual work.
An external service is chosen for high load and a non-standard interface, but it requires honest synchronization: statuses, stock, and payments must converge at a single point.
We select the approach to fit the task, not the other way around — and we document how the solution will behave when the platform is updated.
Implementation stages: from audit to handover
We start with an audit of the ordering scenario: we look at which steps the buyer currently goes through, where the cart is lost, which order properties and statuses are involved, and how the links to warehouses and delivery services are arranged.
The output is a map of the current scenario with bottlenecks and a list of what is holding the business back: non-standard delivery terms, installment payments, one-click ordering for regular customers.
Next, we design the target scheme: we break the checkout down into steps, fix the field validation rules, failure behavior, and integration points with the accounting system. We agree on the scheme before writing code — edits on paper are cheaper than edits in production.
- Ordering scenario audit. We analyze the current buyer journey, the cart logic, order properties and statuses, and find the steps where conversion is lost.
- Scheme design. We describe the checkout steps, validation rules, user roles, payment and delivery scenarios, and the exchange points with the accounting system.
- Checkout setup. We assemble custom steps and fields, connect payment systems and delivery services, and configure cost and terms calculation.
- Integrations. We link the order to the accounting system, warehouse, and CRM: transfer of items, reservations, statuses, notifications.
- Order verification. We run the scenarios end to end — from adding to cart to closing documents, including payment failures and repeat orders.
- Load testing. We observe how the checkout behaves under peak activity: parallel orders, competition for stock, repeated form submissions.
- Handover and training. We hand over documentation, schemes, and instructions, and show the team how to change rules and add new steps.
Each stage ends with a result that can be verified: a scenario map, an agreed scheme, a working checkout step, a test run report. This way the client sees progress on the project, not an abstract "development process".
What the client receives
We hand over not a "finished website" but a package that lets the system be operated and developed without us. Each artifact covers its own class of tasks: configuration, integration, access, staff training.
- Order placement configurations — exported settings for cart, discount, delivery, and payment rules. They allow the logic to be deployed on a test environment and its behavior compared with production.
- Integration diagrams — how order placement exchanges data with the accounting system, warehouse, delivery services, and payment gateways: flow directions, failure points, retries on failure.
- Access policies — a role matrix for administrators, managers, and contractors: who changes order placement rules, who sees customers' personal data, who only reads orders.
- Order placement procedures — step-by-step scenarios for typical situations: editing delivery terms, adding a payment method, handling a stuck order.
- Order documentation — a description of custom logic: which checks fire, in what order, and what happens when an external service fails.
- Staff instructions — how a manager should handle non-standard orders and where to look when data discrepancies occur.
- Change log — what was changed in order placement and why, so that the next enhancement doesn't break the previous one.
- Rollback plan — configuration restore points and the procedure to follow if an update worsens order placement conversion.
The package stays with you: a new contractor or an in-house engineer joins the project based on documentation, not on the previous team's memory. Describe your task — we'll come back with an estimate and a plan.
Case: reducing checkout time
The client is an online store for industrial equipment on 1С-Bitrix: long specifications, carts with dozens of items, payment by invoice and card. The original checkout ran in three steps with mandatory registration before delivery selection.
At the payment step, the user was returned to the cart when changing the delivery method — the cost calculation was reset, and some orders never reached confirmation.
What it was before
We captured metrics over two weeks: average checkout completion time — 4 minutes 20 seconds, the share of successful payments out of started orders — 61%, the most frequent drop-off — the delivery selection step (38% of abandonments). Registration before payment filtered out buyers making one-time purchases.
What was changed
We rewrote the checkout component with custom logic: delivery and payment calculation were moved into a separate layer that recalculates without losing entered data.
Registration was moved to the end — an order can be placed as a guest, and an account is created automatically after payment. We added real-time field validation and cart draft saving so that returning to an order does not start from scratch.
What it became
Average checkout time was reduced to 1 minute 50 seconds. The share of successful payments grew from 61% to 84% — delivery calculation stopped being reset when changing the method. Abandonments at the delivery step fell from 38% to 9%.
The cart draft brought back into the funnel some users who left to clarify the specification and returned later.
The metrics were captured on the same traffic and the same product groups — the comparison is valid.
How does custom checkout differ from the standard one?
The standard checkout is a builder with a fixed set of steps: cart, contacts, delivery, payment. As long as a store sells to individuals with delivery to an address, it is enough.
As soon as a second type of buyer appears, pickup from a partner's warehouse, or payment by invoice with deferred payment, workarounds begin: extra order properties, manual processing by a manager, hacks in the template. The logic stays in the employee's head rather than in the system.
Custom checkout is when the order scenario is designed around your sales model rather than adjusted to fit it.
Steps are assembled dynamically: selecting a legal entity pulls in the company details and deferred payment terms, selecting pickup removes the address block and adds a point selection, a cart with oversized goods offers delivery by crane truck.
The user sees only the fields that apply to their case — the form does not intimidate and does not force them to fill in anything unnecessary.
The flexibility of the logic shows up in validations and calculations. A discount can depend on the order total, product category, customer history, and shipping warehouse all at once. Delivery cost is calculated by zones, weight, dimensions, and unloading method.
A promo code is restricted by products, regions, and customer type. All of this works on the server side, so the rules cannot be bypassed by editing the page in the browser.
Integrations are the second half of the task. The order goes to 1C with correct company details and status, reserves the goods at the required warehouse, registers the deal in the CRM, sends the invoice and a notification to the responsible manager.
If the exchange is unavailable, the order is not lost: it is queued and sent again, and the buyer sees a clear status instead of an error.
Non-standard scenarios are what most often drive the request for customization: an order to multiple addresses, partial shipment, invoice approval, purchase via leasing, checkout on behalf of a division.
The standard module does not support such branches, and every attempt to work around it manually is a risk of error and a lost order.
Common technical concerns
Custom checkout lives inside the 1C-Bitrix core, not alongside it: its own steps, fields, and delivery calculation rules are wired in through standard events and component template overrides.
That way, platform updates don't break the logic — provided the changes are made in a child template and a module, not in core files. Below are the concerns that most often come up before work starts.
Will Bitrix updates wipe out our custom logic?
No, as long as the code sits in the right layer. We don't touch core files or standard components; instead, we move the logic into a custom module and a child template, subscribing to events through handlers. A platform update changes the core — our files remain untouched.
Before every update, we run checkout through a test scenario on a copy to catch conflicts before production.
How will a custom checkout handle the load during a sale?
The bottleneck is usually not the order itself, but the delivery and discount calculation that calls external services. We cache reference data, move heavy checks into deferred tasks, and limit the number of synchronous requests to delivery services.
The cart and checkout run on the standard tagged cache — when a product changes, only the related block is invalidated, not the entire page.
Can checkout be migrated from another engine?
Yes, we migrate the step logic, calculation rules, and links to products, warehouses, and delivery services. First we document the current order scenarios, then reproduce them on the Bitrix side and verify the result against test orders. Customer data and order history are migrated as a separate stage with integrity checks.
Is custom checkout compatible with 1C and Bitrix24?
Exchange with 1C runs over the standard protocol: orders, statuses, and stock are synchronized on a schedule, not at the moment of checkout, so the customer isn't kept waiting.
If an order needs to go to Bitrix24, we connect it as a separate channel — a deal is created after successful payment, and duplicates are excluded by order ID.
Let's discuss your checkout task
To come back with an estimate and a plan rather than generalities, we need a minimum of input from you. Let's gather it in one message — that will be enough to discuss the task concretely and give you timelines.
- Current checkout scenario: a standard component, a custom template, or a multi-step build — and what exactly is unsatisfactory about it.
- Order business logic: delivery and payment terms, discount rules, minimum amount, binding to warehouses and regions.
- Integrations: 1C, payment systems, delivery services, CRM, warehouse — what is already connected and what needs to be added.
- Constraints: platform version, edition, modifications by third-party contractors that must not be touched.
- Access: a test environment, repository, database dump — so the estimate is based on code, not guesswork.
- Priorities: what is critical in the first iteration and what can be moved to the second.
- Expected result: cart conversion, checkout speed, reduction of manual operations — by which metrics you will measure success.
Based on these points, we will analyze the current logic, estimate the scope of work, and come back with a plan: stages, rollout order, rollback points. If some data is unavailable — let us know, and we will advise how to gather it without stopping sales.