<b>Подписка ломается не на оплате, а на управлении её жизненным циклом</b>

<b>Подписка ломается не на оплате, а на управлении её жизненным циклом</b>

Триал, промо-период, апгрейд, пауза, отмена — это не UI-состояния, а финансовые ветки с разной логикой признания выручки и доступа. Если их хранить как набор флагов, система быстро приходит к конфликтам: активен trial, но уже списан renewal; промо закончился, но entitlement не пересчитан; пользователь сменил план, а старый период ещё «доживает» в кэше.

Надёжная модель строится вокруг событий и состояний: pending → trialing → active → past_due → canceled. Для каждого перехода нужно определить, кто источник истины: биллинг, провайдер платежа или entitlement-service. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы. Без неё повтор webhook'а легко превращается в двойной доступ или двойное списание.

Триалы и промо-периоды опасны тем, что их часто считают бесплатным приложением к подписке. На деле это отдельные политики: лимит на повторный trial, правило досрочного апгрейда, перерасчёт остатка при смене тарифа, запрет на overlapping-discount. Если апгрейд происходит внутри оплаченного периода, нужна точная prorate-логика: либо немедленный перерасчёт, либо перенос даты биллинга, но не смесь обоих вариантов.

Пагубная ошибка — смешивать расчёт денег и выдачу доступа в одном сервисе. Лучше разнести: billing фиксирует инвойс, payments подтверждает факт денег, entitlement управляет правом использования, а dunning обрабатывает неуспешные списания и повторные попытки. Тогда при сетевом сплите шлюза вы не потеряете ни выручку, ни контроль над доступом.

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