Налаштування підписних платежів на 1С-Бітрікс

Налаштування підписних платежів на 1С-Бітрікс

Підписна монетизація — бізнес-логіка поверх рекурентних платежів. У Бітрікс немає нативного модуля підписок, реалізація завжди кастомна. Складність не в самому списанні (воно вирішується за 1–2 дні), а в управлінні життєвим циклом: зміна тарифу, тріальний період, скасування зі збереженням доступу до кінця періоду, retry при невдалому платежі.

Ми розробляємо такі рішення для клієнтів уже більше семи років. За цей час зіткнулися з типовими проблемами: несумісність API платіжних шлюзів, дублювання платежів, втрата даних при збоях cron, складність обробки часткових повернень. Наш досвід показує, що без продуманої архітектури підписний бізнес втрачає до 20% виручки через невдалі списання та відтік клієнтів. Наприклад, при значному середньому чеку та великій кількості активних підписників відтік через помилки білінгу може призводити до суттєвих фінансових втрат. Правильна реалізація рятує ці гроші.

Проблеми, які вирішуємо

Гнучке управління тарифами

Готові модулі часто не підтримують складні сценарії: тріали, фріміум, сімейні плани. Ми створюємо кастомну логіку, адаптовану під ваш бізнес.

Надійний білінг

Планувальник з retry-механізмом мінімізує втрати від невдалих платежів. Кожна спроба логується, при вичерпанні спроб підписка призупиняється, а клієнт отримує сповіщення.

Інтеграція з еквайрингом

Потрібна коректна настройка rebill_id через API Тінькофф, Сбера або ЮKassa. Ми забезпечуємо безшовну передачу токенів і обробку холдів.

Як ми це робимо

Стек: PHP 8.1+, Бітрікс (інфоблоки v2.0, ORM), MariaDB, cron, REST API. Для зберігання тарифів і підписок використовуємо окремі таблиці (див. структуру нижче). Кешування теговане — кеш скидається при зміні підписки. Всі критичні операції обгорнуті в транзакції.

CREATE TABLE b_subscription_plans ( id SERIAL PRIMARY KEY, code VARCHAR(32) UNIQUE NOT NULL, name VARCHAR(128), price DECIMAL(10,2), currency CHAR(3) DEFAULT 'RUB', period_days INT NOT NULL, trial_days INT DEFAULT 0, is_active BOOLEAN DEFAULT TRUE ); CREATE TABLE b_user_subscriptions ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, plan_id INT REFERENCES b_subscription_plans(id), rebill_id VARCHAR(128), status VARCHAR(16) DEFAULT 'trialing', trial_ends_at TIMESTAMP, period_start TIMESTAMP, period_end TIMESTAMP, cancel_at_period_end BOOLEAN DEFAULT FALSE, retry_count INT DEFAULT 0, last_payment_at TIMESTAMP, created_at TIMESTAMP DEFAULT NOW() ); 

Статуси: trialing → active → past_due → paused / cancelled / expired. Приклад коду білінг-планувальника:

// /local/cron/subscription_billing.php // Cron: 0 9 * * * php /var/www/shop/local/cron/subscription_billing.php define('NO_KEEP_STATISTIC', true); require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; $db = Bitrix\Main\Application::getConnection(); $due = $db->query(" SELECT s.id, s.user_id, s.rebill_id, p.price, p.currency, p.period_days, u.EMAIL FROM b_user_subscriptions s JOIN b_subscription_plans p ON p.id = s.plan_id JOIN b_users u ON u.ID = s.user_id WHERE s.status = 'active' AND s.cancel_at_period_end = FALSE AND DATE(s.period_end) = CURRENT_DATE "); while ($row = $due->fetch()) { try { $success = chargeRebill($row['rebill_id'], $row['price'], $row['currency']); if ($success) { $db->query("UPDATE b_user_subscriptions SET period_start = period_end, period_end = period_end + INTERVAL '" . (int)$row['period_days'] . " days', retry_count = 0, last_payment_at = NOW() WHERE id = " . (int)$row['id']); createBitrixOrderForSubscription($row); } else { $db->query("UPDATE b_user_subscriptions SET status = 'past_due', retry_count = retry_count + 1 WHERE id = " . (int)$row['id']); sendPaymentFailedNotification($row['EMAIL']); } } catch (\Exception $e) { logError('billing', $row['id'], $e->getMessage()); } } 

Як управляти життєвим циклом підписки?

Після успішного списання оновлюються дати періоду та скидається лічильник retry. При відмові в списанні статус переводиться в past_due, запускається ланцюжок повторних спроб. Якщо клієнт скасовує підписку, ми зберігаємо доступ до кінця оплаченого періоду (cancel_at_period_end = TRUE). Планувальник не буде створювати новий платіж за такою підпискою.

Приклад функції перевірки активної підписки:

function userHasSubscription(int $userId, string $planCode = null): bool { $db = Bitrix\Main\Application::getConnection(); $sql = "SELECT COUNT(1) FROM b_user_subscriptions s JOIN b_subscription_plans p ON p.id = s.plan_id WHERE s.user_id = " . (int)$userId . " AND s.status IN ('active', 'trialing') AND s.period_end > NOW()"; if ($planCode) { $sql .= " AND p.code = '" . $db->getSqlHelper()->forSql($planCode) . "'"; } return (int)$db->queryScalar($sql) > 0; } // В шаблоні закритого розділу if (!userHasSubscription($USER->GetID(), 'premium')) { LocalRedirect('/subscribe/?redirect=' . urlencode($APPLICATION->GetCurPage())); } 

Чому кастомна реалізація краща за готові рішення?

Готові модулі (наприклад, з Маркетплейсу) часто обмежені стандартними сценаріями: вони не дозволяють гнучко налаштувати retry, пропорційний білінг або інтеграцію з унікальною CRM. Кастомне рішення дає повний контроль над логікою — ви самі вирішуєте, коли списувати, які сповіщення надсилати, як обробляти повернення. Крім того, ми можемо інтегрувати підписну систему з будь-яким еквайрингом: Тінькофф, Сбер, ЮKassa, АТОЛ.

Кейс: SaaS-платформа, перехід на підписки

Наш клієнт — B2B-сервіс автоматизації звітності на Бітрікс. До цього — одноразові ліцензії. Завдання: перевести клієнтів на щомісячну підписку з автоматичним продовженням. Зробили: три тарифні плани, білінг через Тінькофф з rebill_id, окремий ОС управління підпискою, email-сповіщення за 3 дні до списання, retry через 1/3/7 днів. Інтеграція з системою доступів — через перевірку userHasSubscription() у кожному захищеному компоненті. Результат: відтік клієнтів знизився на 15%, регулярний дохід зріс у 2 рази.

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

• Аналіз бізнес-вимог та проєктування архітектури.
• Створення БД та моделі даних.
• Розробка API для управління підписками (створення, зміна, скасування).
• Інтеграція з еквайрингом (Тінькофф, Сбер, ЮKassa).
• Налаштування cron-планувальників та retry-логіки.
• Тестування всіх сценаріїв та навантажувальне тестування.
• Документація по API та адмініструванню.
• Навчання ваших розробників.
• Гарантійна підтримка 3 місяці.

Процес роботи

1. Аналітика — обговорюємо тарифну сітку, сценарії підписок, варіанти оплати.
2. Проєктування — створюємо схему БД, API, документацію.
3. Розробка — пишемо код на PHP, версіонуємо через Git.
4. Тестування — unit-тести, інтеграційні сценарії, перевірка на бойових даних.
5. Деплой — налаштування cron, міграції, навантажувальне тестування.
6. Підтримка — моніторинг, доопрацювання, 24/7 на зв'язку.

Терміни орієнтовно

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