Development of a custom 1C-Bitrix order form

Custom Order Checkout Development for 1C-Bitrix

The standard bitrix:sale.order.ajax component, for all its configuration flexibility, has rigid architectural limitations: the checkout form is server-rendered with AJAX updates to individual blocks — not a reactive interface. Adding complex conditional logic (for example, a real-time delivery calculator or dynamic field switching based on cart item types) without rewriting the component is practically impossible. For this reason, custom checkout means either deeply extending the standard component or building a new one from scratch on top of the sale module API.

Custom Checkout Architecture

A custom checkout is built on two layers:

Server side — a controller that:

1. Receives form data via AJAX
2. Validates it (payer type, required fields from b_sale_order_props_variant)
3. Creates an order via \Bitrix\Sale\Order::create()
4. Calculates delivery via \Bitrix\Sale\Delivery\Services\Manager::getById()
5. Applies discounts and coupons via \Bitrix\Sale\DiscountCouponsManager
6. Returns JSON with the result or errors

Client side — a React/Vue component that manages form state, shows/hides fields based on user choices, and displays the current delivery cost without a page reload.

Example of programmatically creating an order:

$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();

Conditional Field Logic

Custom checkout enables flexible field display logic. Examples:

• When "Legal entity" is selected — show fields for company tax ID, KPP, and bank account
• When "Russian Post" delivery is selected — hide address fields and show a parcel locker list via CDEK/Boxberry API
• When the cart contains items from the "Oversized" category — automatically remove "Courier delivery" from the available options

On the server, such rules are implemented via sale module event handlers: OnSaleComponentOrderMakeOrder, OnSaleDeliveryServiceCalculate. On the client — via the component's state machine.

Real-Time Integration with Delivery Service APIs

The standard component calculates delivery cost when the delivery step loads. A custom checkout can implement on-the-fly calculation — as the address is typed. Example with DaData + CDEK:

1. As the address is entered — a request to the DaData API to standardise the address and obtain coordinates
2. Coordinates are passed to the CDEK API /v2/calculator/tariff with cart weight parameters
3. The result is shown to the user before they select a delivery method — they see the price at the address entry stage

This requires a proxy controller on the Bitrix side (to avoid exposing API keys to the client) and proper result caching by key {postal_code}_{weight_kg}.

Case Study: Checkout with Order Splitting by Supplier

Client — a marketplace where a single order can contain items from different suppliers with different delivery terms. The standard checkout does not support shipments from multiple suppliers in one order.

Solution: a custom checkout was developed that, when items are added, analyses PROPERTY_VENDOR_ID for each cart line item and groups them by supplier. A separate delivery selection block is shown for each group. The final order in Bitrix is created as a single order but with multiple shipments (b_sale_shipment), each linked to its own supplier and delivery service.

The complexity: calculating the final total taking into account that different suppliers may have different free-shipping thresholds. Implemented via a dedicated calculation service with Redis caching.

What Is Included in Development

• Audit of the current checkout business logic and requirements
• Server-side API development (controllers, validation, order creation)
• Frontend component development (React/Vue or vanilla JS)
• Integration with payment systems (YooKassa, Sberbank, Tinkoff)
• Integration with selected delivery services
• Scenario testing: anonymous user, authenticated user, legal entity, individual, various delivery/payment combinations

Timeline

Custom order checkout — from 10 working days to 2 months depending on the number of payer types, delivery services, and payment systems, and the presence of non-standard business logic. Basic variant (one payer type, 2–3 delivery services, 1–2 payment systems) — 2–3 weeks.