Single-page checkout in 1C-Bitrix: where buyers are lost
The standard checkout in 1C-Bitrix is built as a sequence of separate steps, and each transition between them is a point where a buyer can leave.
The cart, authorization, delivery address, and payment live on different pages: data is moved into the session, and on refresh or going back, part of the state is lost, and the person sees an empty form instead of the one already filled in.
In our experience, such breaks account for the main share of abandoned carts — not because the customer changed their mind, but because the checkout forced them to start over.
The second bottleneck is validation. Errors in fields like phone or zip code surface not immediately, but after submitting a step, often in a generic form, without indicating the specific field.
The buyer does not understand what exactly to fix, tries again, gets the same error, and closes the tab. At the last step, before confirming payment, this costs the most: the cart is assembled, delivery is selected, but the order is never created.
The third reason is the fragmentation of steps as such. The more screens a person goes through, the higher the cumulative drop-off, and the harder it is to understand at which exact stage checkout conversion is lost.
Standard statistics show the fact of an abandoned cart, but do not show where exactly the buyer stumbled.
Single-page checkout in 1C-Bitrix brings the cart, contacts, delivery, and payment together onto one screen with live field validation and preservation of entered data on any refresh. Below we break down how this is structured and what it delivers in terms of checkout conversion.
What a unified checkout screen provides
Moving from step-by-step checkout to a single order screen eliminates the intermediate cart states: instead of four or five page transitions, the buyer follows a single path — order contents, delivery, payment, and confirmation are assembled in one form.
The number of mandatory steps is reduced from five or six to two or three, and each extra screen ceases to be a point at which the buyer closes the tab.
The share of completed orders grows because data is not lost between steps.
When the cart contents, address, and delivery method live in a single form state rather than being reassembled on each page, the buyer sees the final total and terms right away — and does not go back to fix something.
In practice, this removes the main cause of abandoned orders: unexpected delivery cost or hidden terms at the last step.
Cart loading speed directly affects conversion: a unified screen is served in a single request instead of a chain of transitions, and the recalculation of delivery cost and discounts is performed without a full page reload.
Heavy operations — stock checks, delivery calculation, coupon application — are moved to background requests, and the buyer does not wait for the form to "think."
A separate effect is manageability. Form fields, required status, block order, and calculation logic are configured without rewriting the template, so changes in delivery or payment terms do not turn into a separate development task.
We record metrics before and after: number of steps, abandoned cart rate, form response time — and they show exactly where orders are being lost.
Implementation options: standard module, customization, external service
The choice of approach determines how much logic you keep under control and how quickly you can change checkout rules.
The standard module provides a one-page checkout "out of the box," but its behavior is defined by the product: the order of steps, the set of fields, and the delivery calculation logic can only be modified through events and by overriding component templates.
Customizing the template removes these constraints — you control the markup, the order of blocks, and validation, but along with flexibility you take on maintenance: every core update must be checked for compatibility with your modifications.
An external order service moves checkout outside the product and connects to the catalog and inventory via data exchange, which is justified for non-standard logic but adds a point of failure and synchronization delay.
| Option | When it fits | Limitations |
|---|---|---|
| Standard checkout module | Typical scenario: cart, delivery, payment without special rules | You change the logic of steps and fields only through events; some behavior is closed |
| Template customization | You need your own order of blocks, non-standard validation, integrations at the checkout step | Modifications live in the template — core updates require regression testing |
| External order service | Checkout outside the product, complex logic, multiple sales channels | Exchange with the catalog and inventory, synchronization delay, a separate point of failure |
In practice, a hybrid is more often chosen: the standard module as the foundation, with customization applied selectively to the steps where custom logic is needed. This way core updates proceed predictably, and non-standard scenarios do not break the typical customer journey. Let's look at how to choose the boundary between these approaches for your checkout process.
How We Implement One-Page Checkout in 1C-Bitrix
We start the implementation with an audit of the current cart and checkout: we look at which steps the customer goes through, where items are lost, how the rules for delivery, discounts, and taxes are structured.
At this stage, we record which checks and calculations already exist in the system and which ones will have to be added so that the one-page scenario does not break the existing logic.
Then we work in stages — from analysis to handover of the configured checkout.
- Audit of the cart and current checkout: we analyze the order structure, properties, binding to warehouses and delivery services, and identify bottlenecks and unnecessary steps.
- Scenario design: we determine the composition of blocks on a single page — contacts, delivery, payment, confirmation — and the order in which they are filled in.
- Checkout template setup: we assemble the checkout component, display the fields and delivery methods, and configure cost recalculation and validation without page reload.
- Connecting payments and delivery: we link the available payment methods and delivery options, and configure the rules for displaying them according to the order conditions.
- Order testing: we run scenarios with different carts, addresses, and payment methods, and check the calculations, emails, and data transfer to the accounting system.
- Checking on mobile and slow connections: we make sure that steps are not lost and that the form works correctly on a weak connection.
- Handover and training: we hand over the configured checkout, describe the logic of the fields and the rules, and show how to change the composition of blocks without a developer.
At each stage, we verify the result against the original requirements: the order must go through completely, the amounts and delivery must be calculated correctly, and the data must reach the accounting system without manual edits.
This order allows us to implement one-page checkout without breaking already working sales processes.
Form fields, validation, and integrations with 1C
Form fields are not "name and phone," but a set of attributes that goes into the accounting system.
The minimum working set: contact person, method of contact, delivery address with selection from suggestions, payment and delivery method, comment, consent to data processing.
Each field is linked to an order property in 1C-Bitrix, otherwise the value will be lost during export or end up in the wrong column.
- Field requiredness is configured by scenario: for pickup, the address is hidden and does not block submission; for delivery, it becomes required.
- Validation runs on two levels: client-side (phone mask, email format, postal code) and server-side — the one that actually protects against garbage in the database.
- Validation is tied to order properties through rules, not to the markup — when the theme changes, the rules remain functional.
- Field relationships are described by dependencies: selecting a region pulls up the list of cities, selecting delivery pulls up available pickup points.
- Consent to data processing is recorded as a separate property with a timestamp — this is needed for the legal cleanliness of the order.
Synchronization with the accounting system is built on exchange via CommerceML and the standard order exchange mechanisms. An order goes to 1C with a unique identifier, and a status comes back: paid, being assembled, shipped.
If the exchange is unavailable, the order is not lost — it remains in the queue and goes through when the connection is restored, and the manager sees it in the panel.
1C-Bitrix stores the history of status changes, so a discrepancy between the website and the accounting system is visible immediately rather than surfacing during reconciliation.
Such a loop eliminates manual transfer of orders and removes the class of errors where the client has paid but the order never appeared in 1C.
Case: reducing abandoned carts on a marketplace
The client is a home goods marketplace with several thousand active SKUs and a four-step checkout: cart, delivery selection, recipient details entry, confirmation.
Each transition between steps was a separate page load, and the customer's data and selected delivery method were stored in the session.
On mobile, where about two-thirds of traffic came from, the session broke when switching between apps: a person would leave to get their card number or address and come back to an empty cart.
1C-Bitrix in such a configuration doesn't get in the way, but it doesn't help either: the standard checkout component is designed for a step-by-step scenario, and all the validation and delivery recalculation logic is smeared across step handlers.
We moved checkout to a single-page scenario with a unified order state: items, address, delivery method, and promo code live in a single object, steps switch without a reload, and the intermediate state is saved on the server and restored when the user returns to the page.
We separately fixed delivery cost recalculation — previously it only triggered when moving to the selection step, which meant the customer saw the total only after entering their address and often abandoned the order at that point.
Now the cost is recalculated when the cart or address changes and is immediately visible in the summary block, while validation errors are shown next to the field without resetting what's already been filled in.
| Metric | Before | After |
|---|---|---|
| Share of completed orders | 41% | 63% |
| Average checkout time | 4 min 20 s | 1 min 50 s |
| Share of orders from mobile | 58% | 67% |
| Support requests about checkout | ~90 per week | ~25 per week |
The growth in the share of completed orders added to revenue without increasing the ad budget: the same traffic started converting noticeably better.
A month after launch, we added order draft saving for logged-in customers — the share of completed orders grew by a few more points, and repeat orders started being placed in almost one click.
How does single-page checkout differ from multi-step checkout?
Multi-step checkout breaks a purchase into stages: cart, delivery method, payment, confirmation. Each step is a separate page or a dynamically loaded block, with data validation before moving on. The user always sees where they are, and the form stays short.
The downside is extra clicks and points where the tab can be closed: each intermediate page loses some buyers, and on mobile with a long funnel the losses are more noticeable.
Single-page checkout puts all fields on one screen: contacts, delivery, payment, order contents. The user fills out the form from top to bottom and confirms the purchase with a single action.
The win is fewer transitions and fewer reasons to leave; the loss is a long form and the risk that the person won't understand which fields are required. That's why single-page checkout almost always requires thoughtful validation and hints right in the form.
From an implementation standpoint, the difference lies in how data exchange is structured. The multi-step scenario stores state between steps — in a session, cookies, or an intermediate order — and on each transition rebuilds the cart and recalculates delivery.
The single-page variant keeps everything in one request: fields, the selected delivery service, the payment method, and the total amount are recalculated on the fly, without a reload.
This also changes the failure points: in multi-step, a specific step breaks; in single-page, the entire form breaks at once, so error handling is designed differently.
The choice depends on the product and the audience. For one or two items with simple delivery, single-page checkout offers less friction and higher conversion.
For complex orders — many items, multiple addresses, different fulfillment methods — the multi-step scenario is clearer: it doesn't overload the screen and allows data to be validated gradually.
Often the workable solution is a hybrid: a short first step with contacts and delivery, then a single payment screen.
Technically, both variants are implemented on the same engine and don't require rewriting the catalog or integrations with 1С. What changes are the templates of the checkout component, the validation logic, and the cart recalculation rules.
We first look at how the current funnel behaves and where exactly buyers are lost, and only then suggest switching to the single-page scenario or keeping the multi-step one.
Common technical questions about checkout setup
One-page checkout in 1C-Bitrix almost always breaks not on the markup, but at the junction with the existing store logic: a custom template, custom order properties, exchange with 1C.
Below are the things that most often come up during implementation and how they are solved at the configuration level rather than with "crutches".
Is one-page checkout compatible with the current template and components?
Yes, if you rebuild not the entire template, but the checkout layer.
The checkout component outputs properties, the cart, and delivery as separate blocks — they are brought together onto one page via a custom component template, while preserving the standard extensions and handlers.
Custom order properties and cart rules remain functional: we move their output into the new markup rather than rewriting the logic. If the template is heavily customized, we first map out the dependencies — otherwise hidden modifications will surface after launch.
How does one-page checkout affect speed and conversion?
The key is to remove unnecessary reloads and synchronous requests. Checkout steps switch without a full page reload, delivery and discount calculation moves to deferred calls, and heavy checks do not block input.
In practice, this shortens the path from cart to confirmation and reduces the share of abandoned orders at the last step — exactly where the buyer is usually lost.
Will order exchange with 1C break?
The exchange is built on order statuses and properties, not on the page markup. We preserve the mapping of fields, requisites, and statuses, so the export to 1C proceeds as before.
We separately test the scenarios: an order with a new set of properties, partial payment, cancellation — so that no duplicates or "stuck" items appear in the accounting system.
Can we roll back if something goes wrong?
Yes. The work is done on a copy, and the old checkout scenario remains available until confirmation. The switch is controlled, with the ability to revert to the previous variant without losing orders.
Before launch, we run through the key paths: guest, authorized buyer, payment, delivery, exchange with 1C.
If your concern is not covered here — describe the task, and we will come back with an estimate and a plan for your template and exchange configuration.
Let's discuss your checkout order task
The discussion starts not with a template, but with your current checkout scenario: which fields the customer fills in, where they get stuck, which delivery and payment methods are involved, and how the exchange with 1C is set up. This determines both the scope of work and which checks need to be built into the new logic.
Next, we lock in the work plan and project estimate — with stages, timelines, and areas of responsibility. You see exactly what changes in the template, which modules are affected, how the data migration will proceed, and what will remain under support.
- We analyze the current checkout process and bottlenecks: unnecessary steps, required fields, behavior on validation errors.
- We agree on the target one-page checkout scheme: composition of blocks, order, logic for calculating delivery and taxes.
- We define integration points with 1C: order export, stock levels, payment statuses, item synchronization.
- We prepare a work plan with implementation stages, checkpoints, and the order of deployment to the production environment.
- We provide a project estimate by labor costs and timelines, separately noting risks and dependencies on external systems.
- We discuss how the rollback will be set up and what will be included in warranty support after launch.
To come back with specifics rather than generalities, it's useful for us to see your website, access to the admin panel, and a description of how orders currently get into 1C.
If there is no access — screenshots and a short story about the process will suffice: that's enough to estimate the scope of the checkout implementation.
Describe the task — we'll come back with a work plan and project estimate.