Configuring Single-Page Order Checkout in 1C-Bitrix
Single-page checkout is the ONE_PAGE mode of the bitrix:sale.order.ajax component. All blocks (buyer details, delivery, payment) are displayed on one page and updated via AJAX when values change. The request to switch to this format typically follows analytics: a step-by-step checkout with 3–4 pages increases drop-off at each step, while a single-page format shortens the path from "Checkout" to "Pay".
Enabling ONE_PAGE Mode
In the component parameters on the checkout page:
$APPLICATION->IncludeComponent(
'bitrix:sale.order.ajax',
'',
[
'DELIVERY_MODE' => 'ONE_PAGE',
'SHOW_DELIVERY_PICTURE' => 'Y',
'SHOW_DELIVERY_DESCRIPTION' => 'N',
'PAY_FROM_ACCOUNT' => 'N',
'SHOW_VAT' => 'N',
]
);
In ONE_PAGE mode, the component sends an AJAX request on any field change (city change, delivery service selection) and updates the dependent blocks — delivery cost, available payment systems.
Configuring AJAX Block Updates
In the single-page checkout template, the orderAjax object handles AJAX updates — it is initialised in the order_ajax.php template file. When the "City" field changes, orderAjax.updateDelivery() is called, which:
- Fetches available delivery services for the given city via
\Bitrix\Sale\Delivery\Services\Manager::getRestrictedObjectsList() - Calculates the cost of each via
\Bitrix\Sale\Delivery\Services\Base::calculate() - Updates the delivery block without a page reload
If the calculation takes more than 1–2 seconds (for example, the external CDEK API responds slowly) — the user sees a loading spinner. This is normal, but it is worth adding a timeout and caching calculations by city code and cart weight.
Common ONE_PAGE Configuration Issues
Conflicts with SEO plugins. Single-page checkout loads blocks dynamically, so some SEO tools do not see the page content and add redundant meta tags. Solution: exclude the checkout page from indexing via robots.txt and <meta name="robots" content="noindex">.
Data loss on F5. When the page is refreshed on the single-page checkout, the standard component does not restore the entered data. This is a critical UX issue. Solution — save form data to localStorage on every field change and restore it on page load via JS.
Incorrect behaviour with multiple shipments. If the cart contains items with different delivery conditions, ONE_PAGE incorrectly displays the service list. This is a standard component limitation — such cases require custom development.
Configuration Timeline
Switching to ONE_PAGE mode and adapting the template to the design — 1–2 working days. Adding localStorage persistence, delivery calculation caching, and AJAX logic improvements — 2–4 days.