# Подписная модель: как устроены расчеты и работа с партнерами

Источник: https://fw-t.ru/articles/podpisnaya-model-kak-drajver-razvitia-biznesa
Опубликовано: 2021-02-16 · Обновлено: 2026-09-15

Что подписная модель требует от расчетного контура: регулярные списания, пробные периоды, смена плана в середине периода, партнерские продажи и учет доступа.

**Коротко.** Подписка меняет предмет расчета: вместо разовой продажи появляется цикл, который нужно вести. Регулярные списания по расписанию, обработка неуспешных попыток, пробные периоды, смена плана в середине периода с пересчетом остатка, пакеты из нескольких сервисов и расчеты с партнерами, продающими доступ. Все это задачи расчетного контура, а не платежного шлюза.

Подписка меняет предмет расчета. Разовая продажа заканчивается в момент оплаты; подписка с этого момента начинается, и дальше компания ведет цикл: списания по расписанию, отказы платежей, льготные периоды, переходы между планами.

Отраслевая сторона вопроса — на странице [решений для подписочного бизнеса](/industries/subscription). Здесь — что именно требуется от расчетного контура.

## Шесть задач цикла

| Задача | Что должна уметь система |
| --- | --- |
| Регулярное списание | Расписание, обработка неуспешных попыток, льготный период |
| Пробный период | Условия перехода в платный режим, учет использованного объема |
| Смена плана | Пересчет остатка, изменение доступа с нужной даты |
| Пакеты | Сборка предложения из нескольких сервисов, общий остаток и общая скидка |
| Партнерские продажи | Схемы вознаграждения, учет активаций, сверки |
| Учет доступа | Связь состояния расчета с тем, что видит пользователь сейчас |

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

## Почему платежного шлюза мало

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

Эти правила и есть подписочная модель. Пока они живут в коде сервиса, каждое изменение условий — задача разработке. Когда они описаны в [продуктовом каталоге](/products/fw-pc), новый план собирается настройкой.

## Что решить до внедрения

Три вопроса, ответы на которые определяют объем работ:

**Поведение при неуспешном списании.** Сколько попыток, с каким интервалом, что происходит с доступом в это время и когда подписка считается прекращенной.

**Пауза и возврат.** Можно ли приостановить подписку, сколько раз и на какой срок; как считается возврат при отказе в середине оплаченного периода.

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

Система исполнит любой вариант. Сложность проекта определяется тем, есть ли на эти вопросы ответы до его начала.

## Как это выглядело в проектах

[РБК](/cases/case-rbc) монетизировал контент по подписке для РБК Pro и основного сайта — единый контур из восьми продуктов. [Chat2Desk](/cases/case-chat2desk) заменил расчетную платформу из-за стоимости ввода новых тарифов при разных периодах списания. [Первый ОФД](/cases/case-ofd) работает по подписке с корпоративными клиентами и множеством индивидуальных тарифов. [IVI](/cases/project-ivi) продавал доступ через партнерскую сеть.

## Вопросы и ответы

**Чем подписка отличается от разовой продажи для расчетной системы?**

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

**Достаточно ли платежного шлюза?**

Нет, он решает другую задачу. Шлюз проводит транзакцию. Вопросы, когда наступает следующее списание, что делать при отказе карты, сколько длится льготный период и что происходит с доступом при переходе на другой план, остаются за расчетным контуром. Сервис без этой логики упирается в нее на первой нестандартной ситуации.

**Что самое сложное при переходе на подписку?**

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

**Как считаются продажи через партнеров?**

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

**Подходит ли модель для корпоративных клиентов?**

Да, и требования там другие: договоры и счета на юридическое лицо, закрывающие документы, квотирование по подразделениям, индивидуальные условия. В проекте «Первого ОФД» услугой пользуются компании, и расчетный контур учитывает именно эту специфику.

**Что сложного в миграции действующей базы подписчиков?**

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