Биллинг подписок и entitlement: движок SVOD

Кратко

У подписочного бизнеса два движка, которые постоянно путают: биллинг – он собирает деньги, и entitlement – он решает на каждом запуске, имеет ли конкретный зритель право смотреть конкретный тайтл прямо сейчас. Экран paywall, который все рисуют первым, – это лёгкие 10%; тяжёлые 90% – это stateful-сервис entitlement, который должен быть быстрым, никогда не ошибаться и сверяться с тремя источниками правды (вашим собственным биллингом карт, App Store и Google Play). Большую часть выручки сервис теряет тихо – на involuntary churn, когда карты истекают или отклоняются, а это инженерная задача (ретраи, card updater, окна grace) куда больше, чем ценовая. Эта статья – руководство по сборке такого движка: планы, триалы, проратация, dunning, сервис entitlement, биллинг через стор против прямого и правила признания выручки, которых от вас потребует финансовый отдел.

Зачем это нужно

Если вы основатель, продакт-менеджер или CTO стримингового сервиса впервые, биллинг подписок – это та часть платформы, которая в демо выглядит тривиально, а в продакшене превращается в болото. В демо есть цена и кнопка «Подписаться»; в продакшене нужно обработать карту, которая отклонилась при продлении, зрителя, повысившего тариф в середине месяца, подписку Apple, отменённую в настройках iOS без уведомления вашего сервера, финансовую команду, которой нужна корректно признанная выручка для аудита, и защищённый по контракту тайтл, который не должен воспроизвестись ни у кого, чья оплата прервалась. Ошибитесь в entitlement в сторону разрешения – и вы раздадите контент, который обязаны защищать; ошибитесь в сторону строгости – и заблокируете платящих и сами создадите отток. Это машинное отделение SVOD и парная статья-руководство к карте монетизации OTT, которая показывает, где этот движок стоит среди всех способов заработка платформы.

Одна мысль: сложность – в entitlement, а не в paywall

Subscription Video on Demand (SVOD) – взимание регулярной платы за доступ к библиотеке – звучит как решённая задача. Stripe берёт карту, зритель заходит, готово. Именно из-за такой рамки команды недооценивают работу и узнают настоящую систему, только когда она ломается.

Вот различие, которое организует всё остальное. Биллинг – это машина сбора денег: он хранит выбранный план, списывает с карты по расписанию, обрабатывает апгрейды и возвраты, ретраит неудавшиеся платежи. Entitlement – это машина решения о доступе: она отвечает на один вопрос, «можно ли этому зрителю смотреть этот тайтл, на этом устройстве, в этом регионе, прямо сейчас?», и отвечает на каждом запуске. Биллинг работает с месячным ритмом; entitlement – тысячи раз в секунду. Paywall – экран с тарифами и формой карты – это лишь парадная дверь к биллингу. Его можно нарисовать за вечер, и он значит меньше всего.

Сложность entitlement в том, что он stateful, вызывается всегда и не имеет права ошибаться. Считайте его сплавом кассы и вышибалы: вышибала проверяет каждого на входе каждый раз, а касса должна мгновенно знать, оплачено ли членство этого человека, что оно покрывает и со сколькими друзьями он уже стримит на других экранах. Ложное «нет» блокирует того, кто вам платит. Ложное «да» отдаёт фильм студии тому, кто платить перестал, – это нарушение контракта, а не просто упущенная выручка. Entitlement выходит и за пределы биллинга: он несёт те же правила по тайтлу, территории и окну, что кодирует политика лицензий, а данные о просмотрах, которые он порождает, регулируются законами о приватности (VPPA, GDPR, CCPA). Остальная статья строит оба движка и, что важнее, проводку, которая держит их синхронными.

Нажмите, чтобы увеличить

Что на самом деле делает биллинг: четыре механики

Разберите биллинг подписок до основания – и это четыре механики поверх сохранённого способа оплаты. Ни одна из них не paywall; все они – там, где прячутся продакшен-баги и потерянная выручка.

Планы и тиры

План – единица, на которую подписывается зритель: цена, интервал списания (месяц или год) и набор того, что он даёт – какой каталог, какое качество видео, сколько одновременных потоков, с рекламой или без. План – ещё и вход для entitlement; когда вышибала проверяет дверь, план – это его свод правил. Дизайн самих тиров и бандлов – отдельное решение, описанное в статье цены, паковка и решение по монетизации; здесь же нас интересует, как выбранный план исполняется. Чистый дизайн держит гранты плана (потолок разрешения, число потоков, охват каталога) структурированными данными, которые сервис entitlement читает напрямую, а не прозой на странице тарифов.

Триалы

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

Проратация

Проратация – арифметика изменения в середине цикла: когда зритель повышает, понижает тариф или отменяет подписку посреди оплаченного периода, он должен заплатить или получить кредит ровно за те дни, что пользовался каждым планом. Формула везде одна:

прораченное списание = цена плана × (осталось дней ÷ дней в периоде)

Пройдём конкретный апгрейд. Зритель на тарифе \$100/месяц повышается до \$200/месяц на 10-й день 30-дневного цикла, когда остаётся 20 дней:

списание за новый тариф   = $200 × (20 ÷ 30) = $133,33
кредит за старый тариф     = $100 × (20 ÷ 30) =  $66,67
к списанию сразу           = $133,33 − $66,67 =  $66,66

То есть зритель платит \$66,66 сейчас за апгрейд и полные \$200 при следующем продлении. Почти универсальное правило – апгрейды прорачивать сразу (зритель хочет лучший план немедленно), а даунгрейды применять со следующего цикла (пусть допользуется тем, что уже оплачено, и не придётся выдавать неловкие кредиты). Проратация – один из самых хитрых углов биллинга, потому что каждое такое событие порождает учётное последствие, которое должно сойтись, – именно поэтому команды берут биллинговую платформу, а не пишут это руками.

Dunning

Dunning – автоматическая последовательность ретраев и напоминаний, которая запускается, когда платёж за продление не прошёл. Это самая неброская механика и та, что защищает больше всего выручки, ведь большинство потерь подписок – не решение зрителя уйти, а тихо отказавшие карты. Мы выделили dunning в отдельный раздел ниже, потому что цифры там достаточно велики, чтобы изменить ваш бизнес.

Жизненный цикл подписки: один автомат состояний, много краевых случаев

Каждая подписка проходит небольшой набор состояний, и явно их выписать – лучшая защита от багов entitlement. Подписка trialing, затем active, а при неудачном продлении переходит в past-due / grace, где платформа ретраит карту, – и, что критично, обычно сохраняет право зрителя, чтобы временный отказ не прервал платящего клиента посреди сезона. Из grace она либо восстанавливается в active, либо после исчерпания ретраев уходит в canceled и затем expired, и вот тогда право наконец снимается. Отдельный путь win-back пытается вернуть истёкших.

Моделировать это как один явный автомат стоит потому, что entitlement – функция состояния, а не последнего платежа. «Есть валидный платёж» – неверный вопрос; «находится ли в состоянии, дающем доступ» – верный, ведь grace, триалы и возвраты отвязывают доступ от последнего списания. Команды, которые трактуют entitlement как простой булев флаг – оплачено или нет, – это те, кто либо отрезает клиента во время рутинного ретрая, либо стримит ушедшим неделями.

Нажмите, чтобы увеличить

Где собираются деньги: биллинг через стор против прямого

Теперь решение, которое тихо задаёт вашу маржу. Если зритель подписывается внутри вашего приложения на iOS или Android, платёж проводит стор и берёт комиссию. Если он подписывается на вашем сайте (прямой биллинг), вы проводите карту через своего платёжного провайдера и оставляете куда больше доллара. Это не деталь биллинговой команды; это архитектурное решение, которое нельзя чисто переделать задним числом, потому что два пути дают разные деньги, разные данные и разные источники правды – и маржа, наряду с доставкой и кодированием, превращается в runway через модель стоимости OTT.

Начнём с комиссии, потому что она велика. По состоянию на середину 2026 Apple App Store берёт 30% в первый год авто-продляемой подписки и 15% со второго года, со ставкой 15% по программе Small Business для разработчиков с выручкой менее \$1 млн в год (Apple Developer, 2026 – политика вендора, перепроверить). Google Play сегодня берёт 15% с подписок, а по своему мировому соглашению 2026 с Epic переходит на 10% с подписок (и 20% с прочих in-app покупок) в США, Великобритании и EEA с 30 июня 2026, с глобальным развёртыванием к 2027 (Google Play / соглашение с Epic, 2026 – датировано, перепроверить). Оба режима в 2026 в движении после исходов Epic против Apple и Epic против Google, так что считайте каждое число датированным и сверяйте до того, как строить на нём модель.

Превратим комиссию в инженерное решение с арифметикой. Возьмём 100 000 подписчиков по \$9,99/месяц:

валовые сборы               = 100 000 × $9,99            = $999 000 / месяц
in-app, Apple 30% 1-й год   = $999 000 × 0,70            = $699 300 / месяц
прямой web, ~3% за карту    = $999 000 × 0,97            = $969 030 / месяц
разница                      = $969 030 − $699 300        ≈ $269 730 / месяц

Этот разрыв – около \$3,2 млн в год на тех же 100 000 подписчиков, и решает его лишь то, где продана подписка. Поэтому серьёзные SVOD-платформы маршрутизируют регистрации осознанно. Рычаг, которого у игры нет, а у стриминга есть, – исключение для «reader app»: правила Apple относят видеосервисы к «reader»-приложениям, которые могут разрешить зрителю создавать аккаунт, управлять им – и платить – в вебе, а в приложении просто входить, без принудительной in-app покупки (App Store Review Guidelines §3.1.3(a), 2026 – перепроверить). Netflix и Spotify знаменито этим пользуются: кнопки «подписаться» в их iOS-приложениях нет вовсе. В США апрельский 2025 судебный запрет по Epic против Apple дополнительно ослабил правила внешних ссылок; эта область всё ещё в суде, считайте её живой.

Цена прямого биллинга в том, что теперь вы владеете тем, что раньше делал за вас стор: обработкой карт и её границей соответствия PCI-DSS (стандарт безопасности данных индустрии платёжных карт, разобран вместе с транзакционными сценариями в TVOD: аренда, покупка, PPV), фродом, налогами, возвратами и dunning. Большинство команд держат данные карт вне периметра, токенизируя их через провайдера, но ответственность теперь ваша. Таблица ниже – этот компромисс как карта покрытия.

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

Нажмите, чтобы увеличить

Держим биллинг и entitlement синхронными: проблема источника правды

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

Решение – серверный источник правды, питаемый собственными webhooks сторов. Apple шлёт App Store Server Notifications V2, а Google Play – Real-Time Developer Notifications (RTDN) через Google Cloud Pub/Sub; оба пушат сообщение вашему бэкенду при каждом изменении состояния подписки – продлена, отменена, возвращена, вошла в grace, истекла (документация разработчика Apple и Google, 2026). Дисциплинированный конвейер всегда один и тот же из четырёх шагов: проверьте подпись уведомления, чтобы оно действительно было от стора; вызовите server API стора, чтобы получить авторитетное текущее состояние (уведомление – это звонок в дверь, а не само сообщение); дедуплицируйте по ID уведомления, потому что webhooks доставляются «хотя бы один раз» и придут дважды; затем обновите запись entitlement – то единственное место, где все клиенты и paywall спрашивают правду. Постройте это – и отмена в настройках iOS дойдёт до вашего entitlement за секунды; пропустите – и ваши решения о доступе уплывут от реальности.

Поэтому кросс-платформенные сервисы так часто берут агрегатор биллинга (RevenueCat, Adapty и подобные) или строят его аналог: единый слой entitlement, нормализующий Apple, Google и web-биллинг в один ответ на вопрос «что может смотреть этот аккаунт?», чтобы подписка, купленная на iPhone, открывала тот же аккаунт на смарт-ТВ. Агрегатор не собирает деньги иначе; он унифицирует entitlement между сторами, а это и есть по-настоящему трудная часть.

Нажмите, чтобы увеличить

Признание выручки: собрать кэш – не значит заработать выручку

Финансы спросят с биллинга по правилу, которое удивляет инженеров: собранные деньги – не та выручка, которую вы отчитываете. По контролирующим стандартам учёта – ASC 606 в US GAAP и эквивалентному IFRS 15 в мире – выручка подписки признаётся по мере оказания услуги, равномерно по периоду, на который наделён зритель, а не в момент списания (FASB ASC 606; IFRS 15).

Кусачий случай – годовой план. Зритель платит \$120 вперёд за год. В день, когда карта проходит, у вас \$120 кэша, но \$0 заработанной выручки; \$120 лежат обязательством под названием отложенная выручка (deferred revenue), и вы признаёте по \$10 выручки каждый месяц по мере оказания услуги. Бесплатные триалы следуют той же логике – ноль выручки во время триала, признание начинается с конверсии – а возвраты и проратация корректируют заработанное. Почему это важно для сборки, а не только для финансов: ваши записи entitlement и биллинга – это аудиторский след выручки. Если система не может точно сказать, на что был наделён каждый зритель и сколько с него списали по всем апгрейдам, возвратам и периодам grace, компания не сможет чисто признать выручку и пройти аудит. Спроектировать события биллинга как неизменяемый, запрашиваемый журнал с первого дня куда дешевле, чем восстанавливать его потом.

Involuntary churn: тихая утечка выручки, которую чинят инженерией

Большинство представляет отток как решение зрителя отменить подписку. В подписках значительная доля оттока – совсем не это, а involuntary churn, когда зритель хочет остаться, но платёж за продление не проходит: истёкшая карта, исчерпанный лимит, фрод-фильтр банка, таймаут сети. По всей подписочной экономике involuntary churn составляет примерно 20–40% всего оттока, а у стриминга медианная доля involuntary churn – около 2,1% подписчиков в месяц (Slicker, 2025). До 9% регулярных карточных платежей падают с первой попытки (Slicker, 2025). Это выручка, уходящая от людей, которые и не выбирали уходить, – и возвращают её инженерией, а не маркетингом.

Инженерия – это dunning плюс две вспомогательные тактики. Dunning ретраит неудавшееся списание по расписанию и пишет зрителю обновить карту; временный отказ часто проходит со второй-третьей попытки. Card-updater сервис (предлагают Visa и Mastercard через вашего провайдера) автоматически обновляет перевыпущенный номер карты, возвращая до 20% отказов ещё до ретрая (Slicker, 2025). А окно grace держит зрителя наделённым правом и на экране в окне ретраев, чтобы вы не прерывали – и не злили – клиента, которого вот-вот вернёте. Дадим числа на тех же 100 000 подписчиков по \$9,99:

неудачных продлений при 9%   = 9 000 / месяц
выручка под риском            = 9 000 × $9,99   ≈ $89 910 / месяц
возврат при медианных 47,6% dunning  ≈ $42 797 / месяц
возврат при сильной программе ~70%   ≈ $62 937 / месяц
доп. выручка от хорошего dunning     ≈ $20 140 / месяц  (~$242k / год)

Разница между слабым потоком ретраев и сильным – card updater, умный тайминг ретраев, окна grace, хорошие письма – порядка четверти миллиона долларов в год на этом скромном масштабе, и вся она от зрителей, которые хотели платить дальше. Есть и комплаенс-тонкость, кусающая EU-биллинг: по PSD2 Strong Customer Authentication (SCA) первое списание при регистрации должно быть аутентифицировано (обычно 3-D Secure), но последующие регулярные списания квалифицируются как merchant-initiated transactions (MIT) и освобождены – при условии, что вы их правильно помечаете. Пометите неверно – и ваши продления отклоняются из-за аутентификации, которая не была нужна, фабрикуя involuntary churn из ошибки конфигурации. Аналитика, отслеживающая всё это, – в статье churn, удержание и аналитика подписок.

Частая ошибка: сначала строят paywall и трактуют entitlement как булев флаг

Повторяющийся паттерн провала – выкатить видимые 10% и пропустить структурные 90%. Команда строит красивый paywall, подключает Stripe, ставит флаг is_subscribed = true на аккаунте и релизит. Потом приходит продакшен. Продление падает – и булев флаг переключает платящего клиента в «заблокирован» посреди серии, потому что состояния grace нет. Отмена на iPhone не доходит до сервера, потому что никто не потребляет App Store Server Notifications, и аккаунт месяц стримит бесплатно. Зритель апгрейдится и его списывают дважды, потому что проратацию не построили. Финансы не могут закрыть период, потому что события биллинга перезаписывались, а не журналировались. Каждое из этого – одна корневая ошибка: entitlement смоделировали как один булев флаг, привязанный к последнему платежу, вместо состояния, выведенного из сверенного журнала. Лечение – порядок работы: сначала смоделируйте состояния жизненного цикла и синхронизацию с уведомлениями сторов, paywall трактуйте как последнюю и самую лёгкую часть и никогда не делайте локальную веру клиента в покупку источником правды.

Где здесь Фора Софт

Биллинг подписок – это место, где масштаб стриминга встречается с деньгами, и дорогие провалы невидимы, пока не накопятся: выручка течёт через involuntary churn, entitlement уплывает из синхрона с app-сторами, аудит не закрывается, потому что биллинговый журнал не строили как журнал. Фора Софт строит видеостриминговые и OTT/Internet-TV платформы с 2005 года – это 250+ выпущенных проектов для 400+ клиентов, – а значит, мы проводили большинство этих денежных машин: сервисы entitlement, остающиеся корректными под конкурентной нагрузкой, сверку биллинга App Store и Google Play с прямым web-биллингом через один источник правды и потоки dunning и grace, которые тихо возвращают выручку, теряемую большинством платформ. Наша позиция – scalability-first и нейтральность к вендорам: мы стартуем от масштаба, который нужно обслужить, и маржи, которую нужно защитить, а затем строим движок биллинга и entitlement – прямой, in-app или единый поверх обоих, – который действительно нужен вашей модели.

Ключевые выводы

• Биллинг собирает деньги с месячным ритмом; entitlement решает доступ на каждом запуске – сложность в entitlement.
• Моделируйте подписку как явный автомат состояний; доступ – функция состояния, а не последнего платежа.
• Биллинг через стор против прямого – архитектурное решение ценой в миллионы маржи, его нельзя чисто переделать.
• Сделайте серверную запись entitlement единым источником правды, питаемым webhooks App Store и Google Play.
• Большая часть оттока – involuntary; dunning, card updater и окна grace возвращают его инженерией, не маркетингом.
• Собранный кэш – не заработанная выручка; ASC 606 признаёт подписки по периоду услуги, поэтому стройте биллинговый журнал.

Что почитать дальше

• Карта монетизации OTT: подписки, реклама, транзакции
• Paywalls, registration walls и контроль доступа
• Churn, удержание и аналитика подписок