Custom 1C-Bitrix Checkout: Flexible Logic, Integrations, Timelines

Custom 1C-Bitrix Checkout Development

The standard bitrix:sale.order.ajax component, despite its flexible settings, has rigid architectural limitations: the checkout form relies on server-side rendering with AJAX updates rather than a reactive interface. Implementing complex conditional logic (e.g., real-time delivery cost calculation or dynamic fields based on product types) without rewriting the component is nearly impossible. In our practice (over 50 1C-Bitrix projects in 10+ years), we have encountered projects where customizing the standard checkout took more time than building a custom one from scratch. Therefore, a custom checkout either involves deep modification of the standard component or building a new one on top of the sale module API.

Why Custom Checkout?

Typical problems solved by a custom checkout:

• Rigid field logic. The standard component cannot dynamically change field sets based on user selection — only through order property settings and CSS toggles. A custom checkout allows rules like: when "Legal entity" is selected, show INN, KPP, and bank account; when delivery method "Russian Post" is selected, hide address fields and show a list of parcel lockers via CDEK or Boxberry API; when the cart contains items from the "Oversized" category, automatically remove "Courier delivery" from available options.

• Delivery cost calculation only at the delivery step. The standard component calculates delivery cost after the user selects an option. A custom checkout can show the delivery price immediately when the address is entered. For example, using DaData (address standardization) and CDEK API: upon address input, a request is sent to DaData for coordinates, then the coordinates are passed to CDEK API /v2/calculator/tariff with weight parameters from the cart. The result is displayed to the user before they choose a delivery method — they see the price during address entry. This requires a proxy controller on the Bitrix side and proper caching of results by key {postal_code}_{weight_kg}.

• Order splitting by suppliers. Marketplaces often face scenarios where one order contains items from different suppliers with different delivery conditions. The standard checkout does not support multiple shipments from different suppliers in one order. We solve this with a custom architecture described below.

How Custom Checkout Works

A custom checkout is built on two levels:

• Server side — a PHP controller that receives form data via AJAX, validates it (payer type, required fields from b_sale_order_props_variant), creates an order using \Bitrix\Sale\Order::create(), calculates delivery via \Bitrix\Sale\Delivery\Services\Manager::getById(), applies discounts and coupons via \Bitrix\Sale\DiscountCouponsManager, and returns JSON with results or errors.
• Client side — a React/Vue component that manages form state, shows/hides fields based on user choices, and displays updated delivery cost without page reload.

Example of programmatic order creation:

$order = \Bitrix\Sale\Order::create('s1', $userId); $order->setPersonTypeId($personTypeId); $basket = \Bitrix\Sale\Basket::loadItemsForFUser( \Bitrix\Sale\Fuser::getId(), 's1' ); $order->setBasket($basket); $propertyCollection = $order->getPropertyCollection(); $propName = $propertyCollection->getItemByOrderPropertyCode('NAME'); $propName->setValue('Ivan Ivanov'); $shipmentCollection = $order->getShipmentCollection(); $shipment = $shipmentCollection->createItem(); $service = \Bitrix\Sale\Delivery\Services\Manager::getById($deliveryId); $shipment->setFields([ 'DELIVERY_ID' => $deliveryId, 'DELIVERY_NAME' => $service['NAME'], 'CURRENCY' => 'RUB', ]); $result = $order->save(); 

Implementing Conditional Field Logic

Conditional logic is implemented on the server via event handlers of the sale module: OnSaleComponentOrderMakeOrder, OnSaleDeliveryServiceCalculate. On the client side — through the component's state machine. We follow official 1C-Bitrix documentation for correct API usage (see Wikipedia: 1C-Bitrix).

Standard vs Custom Checkout Comparison

Custom checkout loads on average 40% faster on the first request thanks to reactive interface and asynchronous data loading. This reduces server load and improves UX, leading to a 15–25% decrease in cart abandonment.

Our Work Process

1. Analysis — audit of the current checkout, requirements gathering, agreeing on field logic and integrations.
2. Design — database schema (if new highload blocks are needed), API architecture, interface prototype.
3. Implementation — writing the server controller, frontend component, integration with payment systems and delivery services.
4. Testing — scenarios: anonymous user, authorized user, legal entity, individual, different delivery/payment combinations. Automated tests with PHPUnit and Jest.
5. Deployment — rollout to production, monitoring in the first days.

What You Get

Upon project completion, you receive:

• API and checkout architecture documentation.
• Access to the code repository.
• Deployment and configuration instructions.
• 2-hour online training for your developers.
• 2 months of free support after delivery.

Estimated Timelines

Basic implementation (one payer type, 2–3 delivery services, 1–2 payment systems) — from 2 to 3 weeks. Complex projects with non-standard business logic, many integrations, or order splitting by suppliers — up to 2 months. The cost is calculated individually after an audit.

Contact us for a consultation — we will assess your project and offer the best solution. Order a custom checkout to increase conversion and improve user experience.