Подписка ломается не на оплате, а на переходах между статусами и льготами

Подписка ломается не на оплате, а на переходах между статусами и льготами

Жизненный цикл подписки должен быть моделью состояний, а не набором флагов. Минимум: trial, promo, active, past_due, paused, canceled, expired. Для каждого перехода фиксируйте источник события, время действия и правило приоритета, иначе триал легко «перекрывает» платный период, а промо — маскирует реальную дату следующего списания.

Триалы и промо-периоды требуют отдельной логики истечения. • trial не должен продлеваться повторной регистрацией без жесткой проверки идентичности • promo-скидка должна жить в отдельной сущности, а не в цене тарифа • при активации платной подписки льготный период обязан закрываться идемпотентно, чтобы повторный webhook не создал двойной апгрейд.

Апгрейды и даунгрейды лучше исполнять через scheduled change с отложенным вступлением в силу. Это снимает конфликт между текущим расчетным циклом и новой ценой. Если менять план мгновенно, нужно явно определить: пересчитывается ли остаток периода, обнуляется ли доступ к старым лимитам и как ведется кредитование неиспользованной части. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Отдельно проектируйте dunning: past_due — не просто «неуспешная оплата», а режим с ограничениями, повторными попытками и дедлайном на восстановление доступа. Без этого вы смешаете коммерческий отказ, технический таймаут и добровольную отмену, а затем потеряете и выручку, и доверие.

Делайте подписку не объектом с полями, а управляемым состоянием с журналом событий, иначе любой триал, промо или апгрейд превратится в источник revenue leakage.