Почему рекуррентных платежей недостаточно для подписочного бизнеса

Когда впервые задумываются о приёме платежей за подписку и необходимости списания денег каждый месяц, решение кажется очевидным - надо подключить рекуррентные платежи. Открывается документация платёжной системы, там написано «автоматическое повторное списание» и «уведомления клиентам» и кажется, что это, то что нужно.

Через несколько месяцев выясняется, что MRR непонятно как считать, смена тарифа клиентом требует ручного вмешательства, а юридическое лицо, которое хочет платить по счёту раз в квартал, превращается в отдельный квест.

Проблемы начинаются не из-за рекуррентных платежей, а когда от них начинают ожидать задач, для которых они не предназначены.

Что на самом деле делает рекуррентный платёж?

Чтобы понять разницу, стоит посмотреть на то, что происходит под капотом у платёжной системы, когда включается «подписка».

При первой оплате клиент вводит данные карты. Платёжная система токенизирует их, сохраняет не сам номер, а зашифрованный идентификатор. Дальше сервер говорит эквайеру: «через 30 дней спиши с этого токена 990 рублей». Эквайер это делает. Клиент получает уведомление об успешном списании, а вы получаете деньги. Расписание + токен + фиксированная сумма.

Современные платёжные системы умеют и чуть больше: настроить страницу подписки, отправить клиенту письмо при успешном или неуспешном списании, показать в личном кабинете список активных подписчиков. Это полезные надстройки, но они не меняют природу инструмента, он работает с транзакцией, а не с подпиской как сущностью.

Для определённого класса задач этого достаточно. Один тариф, фиксированная цена, клиент либо платит, либо нет и рекуррентов от эквайера хватает. Но как только модель становится чуть сложнее, начинаются вопросы, которые платёжная система в принципе не предназначена решать.

Где кончается эквайринг и начинается бизнес-логика?

Представьте, что клиент хочет сменить тариф в середине месяца с базового на расширенный. С точки зрения платёжной системы это просто разные суммы в расписании. А вот вопрос «сколько он должен доплатить за оставшиеся дни текущего периода» — это уже математика, которую никакой эквайер за вас не посчитает. Пересчёт стоимости пропорционально отработанному времени уже чистая бизнес-логика.

Или совсем другой сценарий: у вас B2B-клиент, который принципиально не платит картой. Он хочет получать счёт, подписывать акт и переводить деньги с расчётного счёта раз в квартал. Для платёжной системы такой клиент просто не существует, у неё нет механики для выставления счёта, отслеживания факта оплаты по реквизитам и привязки поступившего платежа к конкретному клиенту.

Ещё показательнее модель на основе использования, где сумма списания каждый месяц разная: сколько использовал, столько и заплатил. Телефония, облачное хранилище, API-запросы. Эквайер спишет ровно ту сумму, которую ему назовут. Но откуда берётся эта сумма, сколько минут потрачено, какие тарифные пороги применить, есть ли включенные минуты в тариф — это всё за пределами его зоны ответственности.

То же самое с триальными периодами. Эквайер умеет списать деньги через N дней. Но логика «14 дней бесплатно, потом автоматически переход на платный тариф» требует, чтобы кто-то помнил, когда истекает триал, что именно активировать после него, и что делать, если пользователь в процессе триала сменил план.

Подписка — это состояние, а не транзакция

Если рекуррентный платёж — это инструмент для проведения транзакции, то биллинговая система — это слой, который управляет жизненным циклом подписки: от момента, когда клиент выбрал тариф, до момента, когда он отменил подписку или перешёл на другой план.

Биллинг знает, кто из клиентов на каком тарифе, когда следующее списание, сколько должен с учётом скидок и промокодов, как выставить счёт юридическому лицу, как рассчитать MRR с учётом всех изменений за месяц. Это не набор функций — это единая модель данных, которая описывает состояние подписочной выручки в каждый момент времени.

Без внешнего биллинга его неизбежно начинают строить самостоятельно. Сначала появляется таблица «subscriptions». Потом «subscription_history». Потом «invoices». Потом джоба в кроне, который каждую ночь проверяет, у кого истекает подписка. Потом второй — для выставления счетов юрлицам. Потом оказывается, что джоба в кроне иногда падают молча. Через эту историю прошли сотни команд и у неё есть стоимость: месяцы разработки, которые не идут в продукт, и баги в бизнес-критичном коде, которые обнаруживаются в самый неподходящий момент.

Рекуррентные платежи vs биллинг: в чём разница

Проще всего разница увидеть на конкретных задачах.

Прочерки в левой колонке не означают, что рекуррентные платежи чего-то не умеют. Они умеют ровно то, для чего созданы: надёжно списывать деньги по расписанию. Всё, что происходит до и после, — уже не задача эквайера.

Откуда берётся путаница?

Платёжные системы продвигают рекуррентные платежи как решение для «подписок» и формально это верно. Рекуррент действительно обеспечивает регулярное списание, и это часть подписочной модели. Просто маленькая часть.

Слово «подписка» в контексте эквайринга означает одно, а в контексте бизнеса — другое. Для эквайера подписка — это повторяющийся платёж с фиксированными параметрами. Для команды, которая строит продукт с подписочной моделью, — это отношения с клиентом, которые включают тариф, историю изменений, биллинговый цикл, состояние триала, статус оплаты и ещё десяток атрибутов.

Есть и практическая причина путаницы: для простого старта рекуррентных платежей действительно хватает. Проблема в том, что момент, после которой их уже не хватает, сложно увидеть заранее. Она обнаруживается, когда уже обросли кастомной логикой и переехать на нормальный биллинг становится отдельным проектом.

Как понять, что рекуррентов уже мало?

Понять это довольно просто: количество исключений начинает расти быстрее, чем количество клиентов. Один клиент просит сменить тариф посреди периода, другому нужна скидка, третьему — счёт на юридическое лицо, четвёртому — временно приостановить доступ. Каждая такая ситуация требует отдельной логики, которой у рекуррентных платежей нет.

Если для изменения цены, запуска нового тарифа или внедрения новой модели оплаты приходится ставить задачу разработчикам, значит бизнес-логика подписок уже живёт внутри продукта. В этот момент эквайер продолжает исправно проводить платежи, но управлять подписочной моделью становится всё сложнее.

Граница между «хватит эквайера» и «нужен биллинг»

Потребность в биллинге определяется не размером компании и объемом транзакций, а сложностью подписочной модели. Один тариф, никаких изменений планов — рекуррентов от эквайера вполне хватит. Если есть несколько тарифов, тестовые периоды, B2B-клиенты с оплатой по счёту, хотя бы минимальная аналитика по подпискам, то вот здесь начинается территория биллинга.

Многие команды осознают потребность в нём не в момент роста выручки, а в момент роста числа исключений. Клиент просит приостановить подписку на два месяца. Менеджер договорился с корпоративным заказчиком о специальных условиях оплаты и с поквартальной оплатой на расчетный счет. Каждое такое исключение будет маленьким кирпичиком самописного биллинга, который в итоге становится непредсказуемым монолитом.

Вывод

Рекуррентные платежи и биллинг решают задачи с разным уровнем абстракции. Эквайер отвечает за то, чтобы деньги дошли от карты клиента до вашего счёта по расписанию. Биллинговая система отвечает за всё остальное: кто сколько должен, на каком тарифе, с какими скидками, в каком статусе и что с этим делать дальше.

Биллинг сам использует эквайера для проведения транзакций, они не конкурируют, а дополняют друг друга. Путаница возникает, когда инструмент проведения платежей пытаются растянуть до уровня системы управления подписками. Обычно это работает ровно до того момента, пока не появляется первый клиент с нестандартным запросом.