Рекуррентные платежи ломаются не на отказе карты, а на ошибках в dunning-логике

Рекуррентные платежи ломаются не на отказе карты, а на ошибках в dunning-логике

Рекуррентный биллинг нужно проектировать как конвейер с явными состояниями: active, past_due, suspended, canceled. Если попытка списания упала, система обязана записать причину, номер попытки, канал оплаты и идемпотентный ключ. Иначе повторный webhook, дубль от шлюза или ручной ретрай превратятся в двойное списание либо в пропущенный долг.

Dunning-стратегия должна разделять технические и финансовые отказы: временный сетевой таймаут, недостаточно средств, истекшая карта, неверный CVC, антифрод-блок. Для каждого класса — свой темп повторов, окно жизни попыток и правило эскалации. Технические сбои можно ретраить быстро, а финансовые причины требуют смены инструмента оплаты, уведомления клиента и мягкого приостановления доступа. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Критично не смешивать логику списания и логику уведомлений. Платежный оркестратор фиксирует факт отказа, а отдельный workflow строит цепочку писем, push и in-app сообщений. Так проще контролировать консистентность: один и тот же отказ не должен запускать две dunning-цепочки, а успешное обновление карты — не должно ждать следующего batch-скана.

Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки. Если у вас нет журналирования причин отказов, дедупликации попыток и таймаутов по каждому сценарию, вы не управляете подписками — вы просто надеетесь на удачу.