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

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

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

Триал и промо-период нельзя смешивать в одной логике без разделения источника права на сервис. • trial — право без биллинга, • promo — право с ценовым условием, • grace — право после неуспешного списания. У каждого периода свой лимит повторов, своя дата дедлайна и свой набор уведомлений. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Апгрейды должны работать по правилу proration: старая подписка закрывается в момент перехода, новая открывается с корректным расчетом остатка. Для этого нужен атомарный сценарий: зафиксировать изменение тарифа, пересчитать баланс, выпустить счет или кредит-ноту, только потом менять доступ. Если доступ выдается раньше финансовой фиксации, вы создаете revenue leakage на каждом сбое шлюза или повторе webhook.

Отдельно нужен dunning: неуспешное списание не равно отмене. Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки. Держите очереди повторов, backoff, сегментацию по причинам отказа и жесткий лимит на число попыток; иначе вы либо теряете деньги, либо сжигаете платежный трафик на бесполезных ретраях.

Подписка должна жить по правилам консистентности, а не по надежде на «позже синхронизируется».