Настройка подписочных платежей на 1С-Битрикс

Настройка подписочных платежей на 1С-Битрикс

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

Мы разрабатываем такие решения для клиентов уже более семи лет. За это время столкнулись с типичными проблемами: несовместимость API платежных шлюзов, дублирование платежей, потеря данных при сбоях cron, сложность обработки частичных возвратов. Наш опыт показывает, что без продуманной архитектуры подписочный бизнес теряет до 20% выручки из-за неудачных списаний и утечки клиентов. Например, при среднем чеке $90–130./мес и 1000 активных подписчиков отток в 5% из-за ошибок биллинга обходится в $4.5k–6.5k./мес. Правильная реализация спасает эти деньги.

Проблемы, которые решаем

Гибкое управление тарифами

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

Надёжный биллинг

Планировщик с 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 'USD', 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 на связи.

Сроки ориентировочно

Стоимость рассчитывается индивидуально — зависит от сложности интеграций и объёма кастомизации. Свяжитесь с нами для консультации по архитектуре подписок. Закажите разработку подписочного модуля под ваши задачи — мы подготовим коммерческое предложение с точными сроками.