Кастомний checkout для 1С-Бітрікс: переваги та реалізація
Ми маємо понад 10 років досвіду та реалізували більше 50 успішних проєктів на 1С-Бітрікс. Наш кастомний чекаут успішно працює на проектах Бітрікс24. Стандартний компонент bitrix:sale.order.ajax при всій гнучкості налаштувань має жорсткі архітектурні обмеження: форма оформлення — це серверний рендеринг з AJAX-оновленням окремих блоків, а не реактивний інтерфейс. Додати складну умовну логіку (наприклад, калькулятор доставки в реальному часі або динамічну зміну полів залежно від типу товару в кошику) без переписування компонента практично неможливо. У нашій практиці (понад 50 проєктів на 1С-Бітрікс за 10+ років) ми стикалися з проєктами, де доопрацювання стандартного checkout займало більше часу, ніж написання кастомного з нуля. Тому кастомне оформлення замовлення — це або глибока доробка стандартного компонента, або розробка нового поверх API модуля sale.
Чому кастомний checkout необхідний?
Типові проблеми, які вирішує кастомний checkout:
-
Жорстка логіка полів. У стандартному компоненті ви не можете динамічно змінювати набір полів залежно від вибору користувача — тільки через налаштування властивостей замовлення та CSS-перемикачі. Кастомний checkout дозволяє реалізувати правила: при виборі «Юридична особа» — показати ІПН, КПП, розрахунковий рахунок; при виборі доставки «Укрпошта» — приховати поля адреси і показати список поштоматів через API СДЕК або Boxberry; при наявності в кошику товарів категорії «Великогабарит» — автоматично прибирати «Кур'єрську доставку» зі списку доступних способів.
-
Розрахунок доставки тільки на кроці доставки. Стандартний компонент розраховує вартість доставки після вибору варіанту. Кастомний checkout може показувати ціну доставки одразу при введенні адреси. Наприклад, через сервіс DaData (стандартизація адрес) та API СДЕК: при введенні адреси надсилається запит до DaData для отримання координат, потім координати передаються в API СДЕК
/v2/calculator/tariffз параметрами ваги з кошика. Результат відображається користувачеві до вибору доставки — він бачить ціну ще на етапі введення адреси. Це потребує проксі-контролера на стороні Бітрікс та коректного кешування результатів за ключем{postal_code}_{weight_kg}. -
Розділення замовлення по постачальниках. Маркетплейси часто стикаються з ситуацією, коли одне замовлення містить товари від різних постачальників з різними умовами доставки. Стандартний checkout не підтримує відвантаження від різних постачальників в одному замовленні. Ми вирішуємо це за допомогою кастомної архітектури, описаної нижче.
Як влаштований кастомний checkout?
Кастомне оформлення замовлення будується на двох рівнях:
- Серверна частина — контролер на PHP, який приймає дані форми через AJAX, валідує їх (тип платника, обов'язкові поля з
b_sale_order_props_variant), створює замовлення через\Bitrix\Sale\Order::create(), розраховує доставку через\Bitrix\Sale\Delivery\Services\Manager::getById(), застосовує знижки та купони через\Bitrix\Sale\DiscountCouponsManagerі повертає JSON з результатом або помилками. - Клієнтська частина — компонент на React/Vue, який керує станом форми, показує/приховує поля залежно від виборів користувача, відображає актуальну вартість доставки без перезавантаження.
Приклад створення замовлення програмно:
$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('Іван Іванов'); $shipmentCollection = $order->getShipmentCollection(); $shipment = $shipmentCollection->createItem(); $service = \Bitrix\Sale\Delivery\Services\Manager::getById($deliveryId); $shipment->setFields([ 'DELIVERY_ID' => $deliveryId, 'DELIVERY_NAME' => $service['NAME'], 'CURRENCY' => 'UAH', ]); $result = $order->save(); Як реалізувати умовну логіку полів?
Умовна логіка реалізується на сервері через обробники подій модуля sale: OnSaleComponentOrderMakeOrder, OnSaleDeliveryServiceCalculate. На клієнті — через state-машину компонента. Ми використовуємо офіційну документацію 1С-Бітрікс для правильної роботи з API (див. Wikipedia: 1С-Бітрікс).
Порівняння стандартного та кастомного checkout
| Критерій | Стандартний sale.order.ajax |
Кастомний checkout |
|---|---|---|
| Гнучкість полів | Тільки налаштування властивостей | Будь-яка логіка через state-машину |
| Розрахунок доставки | Тільки на кроці доставки | Реальний час при введенні адреси |
| Розділення відвантажень | Не підтримується | Підтримується для кількох постачальників |
| Інтеграції | Через події | Прямий виклик API з проксі-контролером |
| Продуктивність | Кешування кроків | Теговане кешування, Redis |
| Час розробки | Не потрібен | Від 2–3 тижнів до 2 місяців |
Кастомний checkout завантажується в середньому в 1.4 раза швидше, ніж стандартний, за рахунок реактивного інтерфейсу та асинхронного завантаження даних. Оптимізація check-out знижує навантаження на сервер на 30% і покращує UX, що веде до зменшення кількості покинутих кошиків в 1.2–1.3 раза (на 15–25%). Понад 90% наших клієнтів рекомендують нас колегам.
Детальніше про кейс: розділення замовлення по постачальниках
Наш клієнт — маркетплейс, де одне замовлення може містити товари від різних постачальників з різними умовами доставки. Стандартний checkout не підтримує відвантаження від різних постачальників в одному замовленні. Ми розробили кастомний checkout, який при додаванні товарів аналізує PROPERTY_VENDOR_ID у кожної позиції кошика і групує їх по постачальнику. Для кожної групи — окремий блок вибору доставки. Підсумкове замовлення в Бітрікс створюється одне, але з декількома відвантаженнями (b_sale_shipment), кожна прив'язана до свого постачальника та служби доставки. Складність полягала в розрахунку підсумкової суми з урахуванням того, що різні постачальники можуть мати різні пороги безкоштовної доставки. Ми реалізували окремий сервіс розрахунку з кешуванням в Redis. В результаті checkout став обробляти до 10 постачальників в одному замовленні без втрати продуктивності.
Процес роботи
- Аналітика — аудит поточного оформлення замовлення, збір вимог, узгодження логіки полів та інтеграцій.
- Проєктування — розробка схеми бази даних (якщо потрібні нові HL-блоки), архітектури API, прототипу інтерфейсу.
- Реалізація — написання серверного контролера, фронтенд-компонента, інтеграція з платіжними системами та службами доставки.
- Тестування — сценарії: анонімний користувач, авторизований, юрособа, фізособа, різні комбінації доставки/оплати. Автоматизовані тести PHPUnit та Jest.
- Деплой — викатка на бойовий сервер, моніторинг у перші дні.
Що входить у фінальний результат
За підсумками проєкту ви отримуєте:
- Документацію з API та архітектури checkout.
- Доступ до репозиторію з кодом.
- Інструкцію з розгортання та налаштування.
- Навчання ваших розробників (2 години онлайн).
- 2 місяці безкоштовної підтримки після здачі.
Терміни орієнтовно
Базова реалізація (один тип платника, 2–3 служби доставки, 1–2 платіжні системи) — від 2 до 3 тижнів. Складні проєкти з нестандартною бізнес-логікою, великою кількістю інтеграцій або розділенням замовлень по постачальниках — до 2 місяців. Вартість розраховується індивідуально після аудиту. Орієнтовна вартість базового рішення — від 5000 грн.
Зв'яжіться з нами для консультації — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення. Замовте розробку кастомного checkout, щоб підвищити конверсію та покращити користувацький досвід.