Розробка кастомного кошика 1С-Бітрікс: повний гайд з кейсами

Ми стикалися з ситуацією, коли стандартний кошик 1С-Бітрікс не справлявся з нестандартними вимогами: збереження кошика без авторизації, кастомні поля, складні конфігуратори. У таких випадках необхідна кастомна розробка. Ми допоможемо вам реалізувати кошик під ключ за термін від 5 днів до 6 тижнів — оцінимо ваш проєкт і запропонуємо рішення. Наш досвід включає десятки реалізованих проєктів, і ми гарантуємо сумісність з усіма модулями 1С-Бітрікс.

Стандартний компонент bitrix:sale.basket.basket закриває базові задачі, але ламається під нестандартні вимоги бізнесу: немає збереження кошика між сесіями без авторизації, неможливо додати кастомні поля до позиції (наприклад, гравіювання або колір упаковки), а верстка компонента — це складний шаблон із застарілою структурою. У таких випадках кошик розробляють з нуля або глибоко переробляють стандартний компонент. Економія часу на розробку може досягати 30% при правильному аудиті.

Як влаштований кошик в Бітрікс

Кошик зберігається в таблиці b_sale_basket. Кожна позиція — рядок з полями: FUSER_ID (ідентифікатор анонімного користувача із сесії), PRODUCT_ID, QUANTITY, PRICE, CUSTOM_PRICE (флаг ручної ціни), NOTES, PRODUCT_XML_ID та набір полів PROPS — це серіалізовані властивості позиції з b_sale_basket_props.

Робота з кошиком через API:

// Додавання товару
$basket = \Bitrix\Sale\Basket::loadItemsForFUser(
    \Bitrix\Sale\Fuser::getId(),
    \Bitrix\Main\Context::getCurrent()->getSite()
);

$item = $basket->createItem('catalog', $productId);
$item->setFields([
    'QUANTITY' => 2,
    'CURRENCY' => 'UAH',
    'LID' => 's1',
    'PRODUCT_PROVIDER_CLASS' => '\Bitrix\Catalog\Product\CatalogProvider',
]);
$basket->save();

Для AJAX-операцій з кошиком (додати, змінити кількість, видалити) використовується контролер \Bitrix\Sale\Compatible\DiscountCompatibility або власний Ajax-обробник через \Bitrix\Main\Engine\Controller.

Чому стандартного кошика недостатньо?

Кастомні властивості позиції. Стандартний кошик не дозволяє додати довільні поля до позиції — наприклад, текст для гравіювання, вибраний розмір упаковки або дату доставки конкретного товару. Під капотом це таблиця b_sale_basket_props з полями NAME, VALUE, CODE. Для кастомних властивостей потрібно:

• Додати UI в шаблон сторінки товару (модальне вікно, поля форми)
• При додаванні в кошик передати властивості в AJAX-запиті
• В обробнику додати їх через $item->getPropertyCollection()->createItem()
• Відобразити в шаблоні кошика

Збереження кошика без авторизації. За замовчуванням FUSER_ID — це сесійний ID, і при зміні браузера або пристрою кошик зникає. Для збереження потрібно зберігати FUSER_ID в cookie з довгим TTL (30–90 днів) і при першому відвідуванні створювати запис в b_sale_fuser, прив'язану до цієї cookie. При авторизації — злиття анонімного кошика з кошиком користувача через \Bitrix\Sale\Basket::mergeBasket.

Міні-кошик в хедері з AJAX-оновленням. Стандартний компонент bitrix:sale.basket.small при кожному запиті смикає БД. На високонавантажених магазинах це помітно: 200 RPS × N запитів до b_sale_basket. Рішення — зберігати лічильник кошика в Redis (через \Bitrix\Main\Data\Cache з тегуванням) і оновлювати тільки при змінах, а не при кожному рендері сторінки.

Мультивалютний кошик. При продажу в декількох валютах необхідно коректно перераховувати ціни через CCurrencyRates::ConvertCurrency і зберігати як вихідну ціну у валюті, так і еквівалент у базовій. Стандартний компонент це робить, але без можливості показати «ціну у вашій валюті» поруч із ціною в USD.

З нашої практики: кошик з конфігуратором для будівельного магазину

Клієнт — інтернет-магазин будівельних матеріалів. Проблема: покупець вибирає плитку, і йому потрібно вказати площу укладки, відсоток бою та спосіб укладки (прямо/діагональ). Підсумкова кількість пачок і ціна повинні розраховуватися на льоту прямо в кошику. Досвід роботи з подібними задачами дозволив нам реалізувати рішення за 4 тижні.

Рішення: розроблено компонент кошика на Vue.js, який спілкується з бекендом через REST API (власний контролер). Конфігуратор — окремий компонент, вбудований у рядок позиції кошика. Дані конфігурації зберігаються в b_sale_basket_props з кодами AREA, BREAKAGE_PCT, LAYOUT_TYPE. При зміні параметрів — перерахунок через AJAX без перезавантаження сторінки. Складність: ціни в каталозі зберігаються за одиницю, а закупівля йде пачками — довелося реалізувати конвертацію в обох напрямках.

Результат: конверсія кошика зросла на 40%, тому що клієнт бачить фінальну суму ще до оформлення замовлення, а не отримує уточнення по телефону. Кастомний кошик на Vue.js швидший за стандартний у 2–3 рази при великих обсягах даних.

Архітектурні рішення при розробці

Вибір підходу залежить від вимог:

При розробці кастомного кошика обов'язково враховуємо:

• Збереження сумісності з модулем sale — знижки, купони, правила кошика повинні продовжувати працювати
• Коректний перерахунок при зміні кількості через OnSaleBasketBeforeSaved
• Валідацію на сервері: не можна довіряти ціні, що прийшла з клієнта
• Обробку ситуації «товар закінчився, поки лежав у кошику»

Що входить в роботу

• Аудит поточного кошика та складання технічного завдання
• Розробка серверної частини: API, обробники подій, робота з інфоблоками та модулем sale
• Розробка фронтенду: кастомні шаблони, Vue.js/React компоненти
• Інтеграція з модулями 1С-Бітрікс: catalog, currency, sale
• Тестування: юніт-, інтеграційне, навантажувальне
• Документація та передача вихідних кодів
• Підтримка після релізу (перший тиждень безкоштовно)

Згідно з документацією 1С-Бітрікс: Керівництво розробника, робота з кошиком через D7 ORM — рекомендований підхід.

А також ознайомтеся з загальною інформацією про платформу на Wikipedia.

Як замовити розробку кастомного кошика?

Зв'яжіться з нами для обговорення вашого проєкту. Ми проведемо аудит поточного кошика та запропонуємо оптимальне рішення. Отримайте консультацію та попередню оцінку термінів і вартості в день звернення.

Терміни та етапи

Розробка кастомного кошика від аналізу до здачі займає від 5 робочих днів до 6 тижнів залежно від складності:

1. Аудит поточного кошика та ТЗ — 1–2 дні
2. Розробка серверної частини (API, обробники подій) — 3–10 днів
3. Розробка фронтенду — 2–15 днів
4. Інтеграція з модулями sale, catalog, currency — 1–5 днів
5. Тестування (юніт, інтеграційне, навантажувальне) — 1–3 дні

Зв'яжіться з нами, щоб обговорити ваш проєкт — ми підберемо оптимальний підхід та оцінимо обсяг робіт.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

• Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
• Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
• Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
• Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
• Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

• Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
• Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
• Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
• Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
• Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

• Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
• Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
• Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
• Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

UX промокоду:

• Поле видно, але не кричить — не відволікає тих, у кого коду немає.
• Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
• Знижка видна в підсумковому розрахунку окремим рядком.
• Можна прибрати промокод і застосувати інший.

UX-оптимізація: дрібниці, які вирішують

Десктоп:

• Прогрес-бар — користувач бачить, де він.
• Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою b_sale_order).
• Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
• Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.

Мобільні:

• Великі кнопки — палець не промахується. min-height: 48px за гайдами Google.
• Правильні типи клавіатури: type="tel" для телефону, inputmode="numeric" для кількості.
• Кнопка «Оформити» зафіксована внизу — position: sticky.
• Згорнуті секції — екранний простір на 375px дорогий.

Обробка помилок:

• «Перевірте номер картки» замість «Payment processing error».
• Автопрокрутка до першої помилки — scrollIntoView({ behavior: 'smooth' }).
• «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.

Інтеграції

• DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
• Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
• НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
• LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
• CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
• Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.

// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

Що входить у роботу

• Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
• Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
• Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
• Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
• Налаштування промокодів, крос-селу, покинутих кошиків.
• Тестування на реальних сценаріях: десктоп, мобільні, планшети.
• Передача документації (опис API, інструкції для менеджерів, доступи).
• Навчання співробітників роботі з новим кошиком.
• Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.