На Бітрікс немає вбудованого механізму регулярних платежів. Кожен проект підписок потребує кастомної розробки — від проектування таблиць до інтеграції з платіжними шлюзами. За 5+ років ми реалізували понад 30 підписочних проектів: від доступу до закритого контенту до автоматичної доставки товарів. Наприклад, для інтернет-магазину косметики побудували систему щомісячних підписок на набори. Вона обробляє 5 000 активних підписок з автосписанням через ЮKassa, успішність списань — 95%+. Підписка — бізнес-модель, за якої клієнт регулярно платить за продукт або послугу. Якщо ви зіткнулися з нестачею функціоналу — ви не одні. Типові рішення не дають гнучкості: потрібно зберігати статуси, управляти періодами, обробляти скасування. Ми пропонуємо готову архітектуру на базі ORM Бітрікс, яка закриває ці завдання.
Які типи підписок бувають на Бітрікс?
Перш ніж проектувати, важливо зрозуміти бізнес-модель. Виділяють три основні типи:
| Тип підписки | Опис | Технічна реалізація |
|---|---|---|
| Доступ до контенту | Платний розділ, закриті матеріали | Групи користувачів + обмеження доступу |
| Товарна підписка | Регулярна доставка товарів | Автоматичне створення замовлень |
| Сервісна підписка | SaaS, ліцензія, техпідтримка | Статус акаунта + автопродовження |
Усі три типи мають спільне: періодичне списання грошей та управління статусом доступу.
Архітектура зберігання даних і агенти
Ядро системи — таблиця підписок. Створюється через ORM Бітрікс (наслідування від \Bitrix\Main\ORM\Data\DataManager). Нова архітектура на ORM в 1.5 рази швидша в розробці порівняно з прямими SQL-запитами. Також вона на 30% зменшує кількість помилок при роботі з даними.
class SubscriptionTable extends DataManager { public static function getTableName(): string { return 'b_local_subscription'; } public static function getMap(): array { return [ new IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new IntegerField('USER_ID', ['required' => true]), new IntegerField('PLAN_ID', ['required' => true]), new EnumField('STATUS', ['values' => ['TRIAL', 'ACTIVE', 'PAST_DUE', 'CANCELLED', 'EXPIRED']]), new DatetimeField('CURRENT_PERIOD_START'), new DatetimeField('CURRENT_PERIOD_END'), new DatetimeField('TRIAL_END'), new StringField('PAYMENT_TOKEN'), new IntegerField('PAY_SYSTEM_ID'), new StringField('CANCEL_REASON'), new DatetimeField('CANCELLED_AT'), new DatetimeField('CREATED_AT'), ]; } } class SubscriptionPlanTable extends DataManager { // ID, NAME, PRICE, CURRENCY, PERIOD_DAYS, TRIAL_DAYS, // IBLOCK_SECTION_IDS, FEATURES (JSON) } Для обробки підписок щодня запускається cron-скрипт — агент. Він знаходить підписки з минулим періодом і намагається списати кошти:
$expiring = SubscriptionTable::getList([ 'filter' => [ 'STATUS' => ['ACTIVE', 'PAST_DUE'], '<=CURRENT_PERIOD_END' => new DateTime(), ] ])->fetchAll(); foreach ($expiring as $sub) { try { $result = chargeSubscription($sub); if ($result->isSuccess()) { SubscriptionTable::update($sub['ID'], [ 'STATUS' => 'ACTIVE', 'CURRENT_PERIOD_START' => new DateTime(), 'CURRENT_PERIOD_END' => (new DateTime())->modify('+' . $planPeriodDays . ' days'), ]); } else { handlePaymentFailure($sub); } } catch (\Exception $e) { logError($e, $sub); } } Як налаштувати рекурентні платежі?
Найскладніша частина — автоматичне списання. Ми підключаємо ЮKassa або CloudPayments — обидві підтримують збереження картки та повторні платежі через API. Для вибору порівняйте характеристики:
| Параметр | ЮKassa | CloudPayments |
|---|---|---|
| Простота інтеграції | Висока | Середня |
| Гнучкість налаштування помилок | Базова | Розширена |
| Комісія за успішний платіж | 2.5-3.5% | 2.3-3.2% |
Процес:
- Перший платіж — звичайна оплата, отримуємо payment_method_id.
- Зберігаємо токен у SubscriptionTable.PAYMENT_TOKEN.
- При настанні CURRENT_PERIOD_END викликаємо API з токеном.
$payment = new \YooKassa\Client(); $payment->setAuth($shopId, $secretKey); $response = $payment->createPayment([ 'amount' => ['value' => $plan->getPrice(), 'currency' => 'RUB'], 'payment_method_id' => $subscription->getPaymentToken(), 'capture' => true, 'description' => 'Підписка ' . $plan->getName() . ' #' . $subscription->getId(), ]); Додатково реалізуємо обробку невдалих списань з ескалацією: після 3 невдалих спроб підписка переводиться в PAST_DUE, клієнту надсилається повідомлення. Це знижує ризик неочікуваного блокування на 70%.
Як управляти доступом за підпискою?
Для підписок типу «доступ до контенту» використовуємо групи користувачів Бітрікс. Кожному плану — окрема група. При активації додаємо користувача, при завершенні видаляємо. Права на інфоблоки налаштовуються через права груп. Для товарних підписок — автоматичне створення замовлень через кошик. Рішення масштабується до 10 000 активних підписок без просідання продуктивності.
CUser::SetUserGroup($userId, array_merge( CUser::GetUserGroup($userId), [$plan->getGroupId()] )); Управління підписками: особистий кабінет і сповіщення
Мінімальний функціонал сторінки /personal/subscription/:
- Поточний план і статус.
- Дата наступного списання та сума.
- Історія платежів.
- Кнопка «Скасувати» (з опціональним питанням про причину).
- Зміна плану (апгрейд/даунгрейд).
- Оновлення платіжних даних.
При скасуванні підписки доступ зберігається до кінця оплаченого періоду — клієнт отримує те, за що заплатив. Після закінчення періоду він видаляється з групи доступу. Статус змінюється на CANCELLED, потім EXPIRED.
Обов'язкові поштові події:
- SUBSCRIPTION_CREATED — підтвердження підписки.
- SUBSCRIPTION_PAYMENT_SUCCESS — успішне списання.
- SUBSCRIPTION_PAYMENT_FAILED — помилка списання.
- SUBSCRIPTION_TRIAL_ENDING — за 1-3 дні до кінця тріалу.
- SUBSCRIPTION_CANCELLED — підтвердження скасування.
- SUBSCRIPTION_EXPIRED — доступ закрито.
Тріальний період
При створенні підписки з тріалом:
$trialEnd = (new DateTime())->modify('+' . $plan->getTrialDays() . ' days'); SubscriptionTable::add([ 'USER_ID' => $userId, 'PLAN_ID' => $planId, 'STATUS' => 'TRIAL', 'TRIAL_END' => $trialEnd, 'CURRENT_PERIOD_END' => $trialEnd, ]); Агент за 1 день до закінчення тріалу повідомляє користувача. В день закінчення — спроба першого списання. Якщо картка не прив'язана — підписка переводиться в EXPIRED.
Що входить у розробку системи підписок
- Проектування архітектури БД та бізнес-логіки.
- Реалізація ORM-сутностей та агентів.
- Інтеграція з платіжною системою (ЮKassa / CloudPayments).
- Налаштування прав доступу та груп користувачів.
- Розробка особистого кабінету (/personal/subscription/).
- Конфігурація поштових подій.
- Документація та навчання адміністраторів.
- Пост-релізна підтримка 30 днів.
Терміни та вартість
| Варіант | Склад | Термін |
|---|---|---|
| Без рекурренту | Підписка з ручною оплатою, управління доступом | 5-7 днів |
| З рекурентними платежами | Автосписання через ЮKassa або CloudPayments | 10-14 днів |
| Повна платформа | Декілька планів, тріал, ОК, аналітика | 15-20 днів |
Вартість розраховується індивідуально — залежить від складності бізнес-логіки та кількості інтеграцій. Залиште заявку — ми оцінимо ваш проект за 1 робочий день.
Чому варто працювати з нами
- Використання готового модуля скорочує час розробки на 40% порівняно з типовими рішеннями.
- Глибоке розуміння обмежень Бітрікс та способів їх обходу.
- Понад 30 підписочних проектів у портфоліо.
- Наша розробка у 2 рази швидше впроваджується, ніж рішення конкурентів.
- Гарантія 12 місяців на всі роботи та сертифікація фахівців 1С-Бітрікс.
Отримайте консультацію щодо вашого завдання — зв'яжіться з нами через форму на сайті або електронною поштою. Замовте розробку системи підписок під ключ.