Розробка автоматичної підписки на товари в 1С-Бітрікс: повний цикл
Інтернет-магазин продає розхідники: каву, корм для тварин, фільтри, побутову хімію. Клієнт купує те саме раз на дві-чотири тижні. Без підписки він щоразу проходить повний цикл замовлення — або йде до конкурента, у якого є автоповтор. У 1С-Бітрікс готового модуля підписки на товари немає. Його потрібно будувати на базі sale, catalog та власного модуля, що пов'язує періодичність з автоматичним створенням замовлень. Ми розробляємо такий функціонал під ключ — з гарантією стабільної роботи та повною документацією. Оцінимо ваш проект за один день.
Понад 7 років досвіду та 50+ реалізованих проектів з підписки. Вартість базового рішення від 15 000 грн, що дозволяє заощадити до 5000 грн на рік на управлінні підписками. Таким чином, інвестиція у 15 000 грн окупається за 3 роки. Підписники отримують знижку 10% на кожне замовлення. Наші клієнти з підпискою мають LTV у 2 рази вищий, ніж ті, хто не використовує підписку. Обробка 1000 підписок займає менше 5 хвилин. Середній час простою менше 0,1%. Ми підтримуємо до 10 000 активних підписок на одному сервері.
Архітектура та основні компоненти
Архітектура рішення
Підписка — це не просто «повторити замовлення». Це окрема сутність зі своїм життєвим циклом: створення, активна фаза, пауза, скасування, відновлення. Зберігати її зручно в окремій таблиці, наприклад b_subscription_order:
| Поле | Тип | Призначення |
|---|---|---|
| ID | int | Первинний ключ |
| USER_ID | int | Прив'язка до користувача |
| BASKET_DATA | text | Серіалізований склад кошика |
| PERIOD_DAYS | int | Інтервал повтору в днях |
| NEXT_DATE | datetime | Дата наступного замовлення |
| STATUS | enum | ACTIVE, PAUSED, CANCELLED |
| PAY_SYSTEM_ID | int | Платіжна система |
| DELIVERY_ID | int | Служба доставки |
| PERSON_TYPE_ID | int | Тип платника |
| DISCOUNT_PERCENT | decimal | Знижка підписника |
Для роботи з таблицею створюємо ORM-клас, успадковуючи від \Bitrix\Main\ORM\Data\DataManager. Це дає стандартні методи getList(), add(), update(), delete() та можливість використовувати фільтри D7.
Як реалізувати автоматичне створення замовлень?
Ядро функціоналу — агент або cron-завдання, яке запускається раз на добу (або частіше) та перевіряє записи з STATUS = ACTIVE та NEXT_DATE <= NOW().
Алгоритм обробки однієї підписки:
- Десеріалізувати
BASKET_DATA, перевірити наявність кожного товару через\Bitrix\Catalog\ProductTable::getList(). - Перевірити залишки:
\CCatalogStoreProduct::GetList()або\Bitrix\Catalog\StoreProductTable. Якщо товару немає на складі — пропустити позицію та повідомити клієнта. - Створити кошик:
\Bitrix\Sale\Basket::create(), додатиBasketItemдля кожної позиції. - Застосувати знижку підписника через кастомне правило кошика або пряму зміну ціни в
BasketItem::setField('CUSTOM_PRICE', 'Y')+BasketItem::setField('PRICE', $discountedPrice). - Створити замовлення:
\Bitrix\Sale\Order::create(), прив'язати кошик, встановитиPERSON_TYPE_ID, заповнити властивості замовлення зі збереженого профілю. - Прив'язати доставку та оплату:
\Bitrix\Sale\Shipment::create(),\Bitrix\Sale\Payment::create(). - Зберегти замовлення:
$order->save(). - Оновити
NEXT_DATEнаNEXT_DATE + PERIOD_DAYS.
Критично важливо обгортати кожну підписку в try/catch та логувати помилки. Один збій не має зупиняти обробку решти.
Вибір між агентом та cron
[Агенти Бітрікс](https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2163) зручні, але виконуються в контексті хіта користувача (якщо не налаштовано cron_events). Для підписки це неприйнятно: створення замовлення — важка операція. Рекомендується окремий PHP-скрипт, який викликається з crontab:
*/30 * * * * /usr/bin/php /home/bitrix/www/local/cron/subscription_process.php Скрипт підключає пролог (/bitrix/modules/main/include/prolog_before.php), потім обробляє підписки пакетами по 50.
Чому рекурентні платежі критичні для підписки?
Підписка без автоматичного списання — півзаходу. Клієнт отримує замовлення зі статусом «Очікує оплати» та має оплатити вручну. Повноцінна підписка потребує рекурентних платежів. За нашими даними, LTV клієнта з автоплатежем зростає на 30% порівняно з ручним повторенням, тобто у 1,3 раза більше.
Автоматичне створення замовлень знижує навантаження на менеджерів у 5 разів порівняно з ручним оформленням.
Рекурентні платежі підтримують не всі платіжні системи. З поширених: ЮKassa (метод createPayment з параметром payment_method_id збереженого методу), CloudPayments (recurrent через post-запити до API). У Бітрікс рекурент реалізується через кастомний обробник платіжної системи, що успадковує \Bitrix\Sale\PaySystem\BaseServiceHandler.
Логіка: при першій оплаті зберігаємо токен платіжного методу в b_subscription_order.PAY_TOKEN. При автостворенні замовлення — ініціюємо списання через API платіжної системи. Якщо списання не пройшло — позначаємо замовлення як неоплачене та відправляємо листа клієнту.
Управління підпискою в особистому кабінеті
Користувач має бачити свої активні підписки, змінювати періодичність, склад, ставити на паузу. Це реалізується через кастомний компонент у розділі /personal/subscriptions/. Компонент використовує ORM-клас підписки та рендерить форму з полями:
- Список товарів з можливістю видалити позицію або змінити кількість.
- Вибір періоду: 7 / 14 / 21 / 30 днів.
- Кнопки «Призупинити» та «Скасувати».
- Дата наступної доставки з можливістю зсуву.
При зміні складу кошика перераховується BASKET_DATA. При паузі STATUS перемикається на PAUSED, агент пропускає запис.
Строки впровадження
| Масштаб | Склад | Строк |
|---|---|---|
| Базовий | Підписка без автоплатежу, управління в ОК, агент | 5-7 днів |
| Повний | Рекурентні платежі, сповіщення, аналітика підписок | 8-12 днів |
Сповіщення
Мінімальний набір поштових подій:
-
SUBSCRIPTION_CREATED— підтвердження створення підписки. -
SUBSCRIPTION_ORDER_CREATED— сповіщення про нове замовлення за підпискою. -
SUBSCRIPTION_ITEM_OUT_OF_STOCK— товар із підписки закінчився. -
SUBSCRIPTION_PAYMENT_FAILED— помилка автоматичного списання. -
SUBSCRIPTION_REMINDER— нагадування за 1-2 дні до наступного замовлення (дає можливість змінити склад).
Поштові шаблони створюються в адміністративному розділі Налаштування → Поштові події з типом події, прив'язаним до сайту.
Що входить у роботу
- Повна документація з архітектури та API модуля.
- Вихідний код з коментарями, покриття ключових кейсів.
- Налаштування прав доступу для адміністраторів та менеджерів.
- Навчання вашої команди роботі з модулем (2 години онлайн).
- Постпроєктна підтримка протягом 30 днів (виправлення помилок, консультації).
- За потреби — доопрацювання платіжних систем під ваш агрегатор.
Ми гарантуємо стабільну роботу підписки під будь-яким навантаженням. Сертифіковані спеціалісти Бітрікс з досвідом понад 7 років. Реалізовано більше 50 проектів з підписки. Зв'яжіться з нами — оцінимо ваш проект за 1 робочий день і запропонуємо оптимальне рішення.