Configuring 1C-Bitrix Order Checkout: Debugging and Customization

A client complains: the checkout form works on and off. The console throws TypeError: BX is undefined, and the delivery cost doesn't recalculate when the city changes. Statistics show that out of 1000 visitors, 400 abandon the cart precisely because of errors at the final step. This happens when the bitrix:sale.order.ajax component runs with a broken template or incorrect parameters. Over 10 years, we've collected typical scenarios and hard-to-spot pitfalls that occur in 80% of projects. The checkout page is a critical node of any online store — any error here means lost customers and budget.

Problems We Solve

Typical situation: delivery cost doesn’t recalculate when the city is selected. The reason is that the onSaleOrderAjaxLocationChange event isn't configured. The component doesn't know that tariffs depend on location. The solution: subscribe to the event and update delivery services via BX.Sale.OrderAjaxComponent.refreshOrderData(). Another common pain point is a frozen payment spinner, caused by jQuery version conflicts in the template. We check that the template doesn't have duplicate scripts.

Case: CDEK integration solved a 30% order loss. On one project, the client was losing 30% of orders because, even when pickup was selected, the address field was still mandatory. We set up conditional field display using the JS event onSaleOrderAjaxDeliveryChange. After implementation, conversion increased by 25%. We used parameters: DELIVERY_NO_AJAX = 'N' and USE_PREPAYMENT = 'Y'. For more on the component structure, see the 1C-Bitrix documentation.

Component Structure of the Checkout Form

The bitrix:sale.order.ajax component consists of several parts:

• Checkout steps — controlled by the DELIVERY_MODE parameter (SPLIT_DELIVERY for stepwise, ONE_PAGE for single-page)
• Payer types — configured in Web Store → Customers → Payer Types
• Delivery services — added in Web Store → Delivery Services
• Payment systems — added in Web Store → Payment Systems

The component template is located at /bitrix/components/bitrix/sale.order.ajax/templates/. When working with a site under a template, a copy is used in /local/components/bitrix/sale.order.ajax/templates/.

Typical Admin Interface Settings

Order form fields. In Web Store → Settings → Order Properties, you configure fields: name, phone, email, address. For each field, you set the type, requirement, and binding to the payer type.

Linking delivery to warehouses. If your store has multiple warehouses (Catalog → Warehouses), configure which warehouse ships the product. This affects the calculation of delivery cost and time.

City autofill. The component pulls the city from the authorized user’s profile (field UF_CITY from b_user). For anonymous users, it uses geolocation from the sale.location module or an external service (DaData, Yandex.Maps).

Comparison of Checkout Modes

SPLIT_DELIVERY outperforms ONE_PAGE for complex catalogs, reducing cart abandonment by 15-20%. The average conversion in online stores is usually 2-3%, so each percentage point of growth is critical.

How to Integrate Checkout with Geolocation?

Enable the sale.location module and set USE_AJAX_LOCATION = 'Y'. For more precise city detection, use the JavaScript service DaData. Example handler:

BX.addCustomEvent('onSaleOrderAjaxLocationChange', function(location) { // refine city by IP via a third-party API }); 

Geolocation is especially important for stores with regional delivery — it automatically presents available delivery services and their rates.

Why Is Conditional Field Display Important?

A customer selects pickup, yet the form still requires a delivery address. This is frustrating and lowers conversion. The correct solution is to show address fields only when courier delivery is selected. This is implemented via the JS event:

BX.addCustomEvent('onSaleOrderAjaxDeliveryChange', function(deliveryId) { // show/hide fields depending on chosen delivery }); 

This approach improves usability and reduces the number of abandoned orders by 25-30%. A properly configured form can save 20-30% of potential losses due to errors.

How to Set Up Conditional Field Display: Step-by-Step

1. Identify the delivery service IDs for which fields should be shown/hidden.
2. Subscribe to the onSaleOrderAjaxDeliveryChange event in JavaScript.
3. In the handler, compare the received ID and control the visibility of blocks (e.g., via BX.show() / BX.hide()).
4. Test all scenarios: pickup, courier, pickup point.

Configuring Order Property Binding to Delivery

A common task is to show the delivery address only when courier is selected, and when pickup is selected, show a list of pickup points. This is done through the component template parameters:

// In the sale.order.ajax component template $arParams['DELIVERY_NO_AJAX'] = 'N'; // update deliveries without reload $arParams['USE_PREPAYMENT'] = 'Y'; // prepayment 

What's Included in the Work

• Analysis of the current form: console errors, non-working fields, delivery/payment issues
• Logic design: which fields to show when, binding to delivery services
• Configuration of the sale.order.ajax component for your parameters (DELIVERY_MODE, USE_PREPAYMENT, AJAX_LOCATION)
• Integration with delivery and payment: connecting services, setting tariffs, testing
• Testing on all stages: browsers, mobile devices, different scenarios
• Documentation on settings and manager training (how to process orders)

Timeline for Configuration

Basic checkout setup (form fields, delivery services, payment systems) takes 4–8 hours. If conditional field visibility, geolocation, or integration with delivery APIs is required, it takes 1–3 business days. The cost is calculated individually, but a properly configured form can save 20-30% of potential losses due to errors. Your investment pays off through increased conversion and customer LTV.

Order a turnkey configuration — get a checkout form that doesn't lose customers. Our experience of over 10 years and 50+ successful projects is a guarantee of results. Contact us for a consultation.

Source: Wikipedia: CommerceML — a data exchange protocol between 1C and online stores.