Подписка ломается не на оплате, а на границах триала, промо и апгрейда

Подписка ломается не на оплате, а на границах триала, промо и апгрейда

Жизненный цикл подписки должен быть не цепочкой статусов, а конечным автоматом: trial, promo, active, grace, paused, canceled, churned. Если статус меняется без явного события и версии контракта, вы получаете фантомные доступы, двойные списания и спорные продления. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Триал и промо-период нельзя хранить как «просто бесплатные дни». Для каждого периода нужны: дата старта, правило окончания, источник права на доступ, ограничение на повторный запуск и логика конверсии в платный план. Иначе один и тот же пользователь сможет пройти trial повторно через новый канал, а revenue leakage станет системным.

Апгрейд должен считаться как изменение договора, а не как новая подписка поверх старой. Корректная схема: прерывание текущего периода, пропорциональный перерасчет, фиксация остатка, атомарная смена тарифа и журнал причин. Если тарифы пересекаются, система обязана определить приоритеты: что сгорает, что переносится, что тарифицируется немедленно.

Для устойчивости нужны три вещи: event log для аудита, отдельный слой entitlement-логики и дunning-контур для просрочек. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: именно там проверяется, умеет ли система отличать повтор от нового намерения.

Стройте подписку как цепочку явных переходов и проверяйте каждый переход на повтор, задержку и частичный отказ. Тогда триалы не превратятся в дыру, а апгрейды — в источник тихих потерь выручки.