Налаштування оформлення замовлення в розстрочку на 1С-Бітрікс

Налаштування оформлення замовлення в розстрочку 1С-Бітрікс

Ми налаштовуємо оформлення замовлення в розстрочку на 1С-Бітрікс під ключ. При розробці інтернет-магазину часто виникає потреба додати оплату частинами — Халва, Черепаха, Магніт, Карта покупок. Завдання не зводиться до простої вставки кнопки. Потрібно перебудувати флоу чекауту: коли показувати розстрочку, які поля збирати, як передавати дані в банк і обробляти відповіді. За роки інтеграцій ми виявили типові проблеми — неправильна черга відображення кнопок, втрачені заявки через відсутність логів, конфлікти з іншими платіжними системами. Наш підхід — вибудувати наскрізний флоу з мінімальними змінами стандартного чекауту. Середня конверсія при додаванні розстрочки зростає на 15–20%, а середній чек — на 25–30% за рахунок вибору дорожчих товарів.

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

Покупець, бачачи можливість платити частинами, рідше кидає кошик на етапі оплати. Психологічний поріг знижується: замість великої суми одноразово — щомісячний платіж, порівнянний з ціною чашки кави. Для інтернет-магазинів це означає зростання LTV та зниження відмов. За нашими даними, при підключенні Халви або Черепахи конверсія в оплату зростає на 35–40% на категоріях товарів з високою вартістю.

Коли показувати розстрочку

Розстрочка має мінімальну суму замовлення (зазвичай визначається індивідуально). Показувати кнопку «Оформити в розстрочку» потрібно лише коли сума кошика відповідає умовам. Це вирішується в методі isAvailable обробника платіжної системи.

На фронті — динамічне приховування/показ кнопок при зміні кошика через подію basket:updated. Слухач перевіряє підсумок і ховає кнопку, якщо сума менше мінімуму. Заодно на клік оновлюється розрахунок щомісячного платежу.

BX.addCustomEvent('basket:updated', function(e) {
    const total = e.detail.price;
    const minInstallment = window.INSTALLMENT_MIN_AMOUNT || 50;

    document.querySelectorAll('.installment-pay-btn').forEach(btn => {
        btn.style.display = total >= minInstallment ? 'inline-flex' : 'none';
    });

    if (total >= minInstallment) {
        document.getElementById('installment-monthly')
            .textContent = 'від ' + Math.ceil(total / 12) + ' руб./міс.';
    }
});

Як адаптувати чекаут під розстрочку

Стандартний чекаут Бітрікс (bitrix:sale.order.ajax) потрібно адаптувати під розстрочку. Використовується два підходи.

Підхід 1: Єдиний чекаут з умовними полями. У формі замовлення присутні всі поля, але додаткові (для розстрочки) показуються лише при виборі відповідного способу оплати.

BX.bind(document.getElementById('pay-system-select'), 'change', function() {
    const isInstallment = this.value === 'installment';
    document.getElementById('installment-fields-block').style.display =
        isInstallment ? 'block' : 'none';
    document.querySelectorAll('.installment-required').forEach(el => {
        el.required = isInstallment;
    });
});

Підхід 2: Окрема сторінка підтвердження. Покупець оформлює замовлення стандартно, потім на сторінці оплати бачить кнопки: «Оплатити карткою» та «Оформити в розстрочку». При кліку на розстрочку — редирект на сайт банку.

Підхід 2 простіший для реалізації і менше ламає користувацький досвід. Саме він найчастіше застосовується при інтеграції з білоруськими сервісами розстрочки (Халва, Черепаха, Магніт, Карта покупок). Підхід 1 зручніший для покупця, але вимагає ретельної валідації полів та тестування.

Які властивості замовлення потрібні для розстрочки

Для передачі даних в банк створюємо властивості замовлення через модуль sale. Програмно додаємо обов'язкові поля: термін розстрочки, провайдер, ID заявки в банку, статус.

$propsToAdd = [
    'INSTALLMENT_TERM'       => ['NAME' => 'Термін розстрочки (міс.)', 'TYPE' => 'NUMBER'],
    'INSTALLMENT_PROVIDER'   => ['NAME' => 'Провайдер розстрочки', 'TYPE' => 'STRING'],
    'INSTALLMENT_APP_ID'     => ['NAME' => 'ID заявки в банку', 'TYPE' => 'STRING'],
    'INSTALLMENT_STATUS'     => ['NAME' => 'Статус розстрочки', 'TYPE' => 'STRING'],
];

foreach ($propsToAdd as $code => $params) {
    $prop = new \CSaleOrderProps();
    $prop->Add([
        'PERSON_TYPE_ID' => 1,
        'NAME'           => $params['NAME'],
        'TYPE'           => $params['TYPE'],
        'CODE'           => $code,
        'ACTIVE'         => 'Y',
        'USER_PROPS'     => 'N',
        'IS_LOCATION'    => 'N',
        'IS_EMAIL'       => 'N',
        'IS_NAME'        => 'N',
        'IS_PHONE'       => 'N',
        'SORT'           => 500,
    ]);
}

При створенні замовлення через розстрочку заповнюємо INSTALLMENT_TERM та INSTALLMENT_PROVIDER. При отриманні рішення від банку — INSTALLMENT_APP_ID та INSTALLMENT_STATUS.

Що робити після схвалення банку?

Після повернення з сайту банку (success_url) показуємо спеціальну сторінку «Заявка на розстрочку прийнята»:

• Якщо банк схвалив миттєво — «Розстрочку оформлено, замовлення підтверджено»
• Якщо розгляд займе час — «Заявка на розгляді. Ви отримаєте SMS про рішення»
• Якщо відхилено — «Заявку відхилено. Ви можете обрати інший спосіб оплати» з кнопкою «Оплатити карткою»

Статус визначається з GET-параметра, який повертає банк, або з нашої БД (bl_mtbank_orders.status, bl_bnovo_reservations, залежно від провайдера).

Логування та моніторинг

Всі спроби оформлення розстрочки пишемо в лог bl_installment_log. Це дає статистику: конверсія по кожному провайдеру, середній термін розстрочки, частка заявок за сумами.

CREATE TABLE bl_installment_log (
    id          SERIAL PRIMARY KEY,
    order_id    INT NOT NULL,
    provider    VARCHAR(32) NOT NULL,   -- 'halva', 'karta_pokupok', 'cherepaha', 'magnit'
    amount      NUMERIC(12,2),
    term_months SMALLINT,
    status      VARCHAR(30),
    bank_app_id VARCHAR(128),
    created_at  TIMESTAMP DEFAULT NOW(),
    updated_at  TIMESTAMP DEFAULT NOW()
);

Терміни та склад робіт

Порівняння типових параметрів провайдерів:

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

• Технічна документація — опис флоу, схема даних, інструкція з підтримки
• Налаштування платіжних систем та інтеграція з банками
• Доступ до репозиторію з кодом
• Навчання адміністратора: як додавати нового провайдера, де дивитись логи
• Гарантія на роботу — 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.