Подписка ломается не на оплате, а на переходах между trial, promo и upgrade

Подписка ломается не на оплате, а на переходах между trial, promo и upgrade

Жизненный цикл подписки надо проектировать как конечный автомат: trial → promo → paid → grace → cancel. У каждого состояния должны быть свои правила доступа, тарификации и уведомлений. Если статус хранится как одна строка без истории событий, вы теряете причинность: непонятно, почему пользователь получил доступ или почему не случился списание.

Триалы и промо-периоды опасны скрытой неидемпотентностью. Пользователь может завести несколько аккаунтов, сменить платежный метод или вернуться через другой канал. Поэтому ограничения должны опираться не только на account_id, но и на связку identity, device, payment fingerprint и правила антиабьюза. Иначе скидка превращается в утечку выручки.

Апгрейд внутри периода — отдельный сценарий, а не “просто пересчитать сумму”. Нужны proration, отмена старого entitlement, выпуск нового и строгая транзакционная граница между биллингом и выдачей прав. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы. Иначе повтор вебхука или ретрай шлюза создаст двойной charge или вечный доступ.

Для dunning и отмен важно хранить не только текущий статус, но и причину перехода, timestamp, источник события и версию решения. Тогда можно безопасно строить повторные списания, паузу доступа, winback-цепочки и аудит спорных кейсов без ручной реконструкции истории.

Выигрывает не тот, у кого больше статусов, а тот, у кого каждый переход детерминирован, идемпотентен и проверяем на границах между биллингом, entitlement и CRM.