<b>Архитектура подписки ломается не на оплате, а на переходах между состояниями</b>

<b>Архитектура подписки ломается не на оплате, а на переходах между состояниями</b>

Модель подписки нужно проектировать как конечный автомат: trial → promo → paid → grace → canceled → reactivated. Если состояния не формализованы, бизнес начинает считать одну и ту же сущность по-разному: биллинг думает, что триал еще идет, продукт уже открыл доступ, а CRM уже запустила dunning.

Триал и промо-период должны иметь отдельные правила активации и отдельные источники истины. У триала важны дедупликация стартов, защита от повторной выдачи и жесткий контроль eligibility. У промо-периода — ограничение по сегменту, коду, каналу и применимости к конкретному SKU. Смешивать их в одну скидку опасно: потом невозможно объяснить, почему клиент получил льготу дважды.

Апгрейды и даунгрейды нельзя обрабатывать как простую смену тарифа. Нужны prorate-расчеты, идемпотентные команды и явная политика: немедленное изменение доступа или отложенное до конца периода. Давайте разберем, что происходит, если пользователь апгрейдится в момент сетевого сплита шлюза: без idempotency key и ledger-учета вы получите двойное списание или «вечный» grace.

Отдельно фиксируйте события жизненного цикла: activation, renewal_attempt, payment_failed, grace_started, canceled. Это не аналитика, а контур управления риском revenue leakage. Если событие не атомарно записано и не воспроизводимо, dunning будет стрелять вслепую.

Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.