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

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

Если у вас подписка, карта клиента — это не источник денег, а внешний сервис с нестабильной доступностью. Для рекуррентных платежей критичны три вещи: идемпотентный charge, единый ledger и явная классификация отказов. Без этого вы получите двойные списания, расхождение статусов и тихую утечку выручки.

Dunning-стратегия должна быть не набором “ещё раз попробуем”, а машиной принятия решений:
— soft decline: повтор по расписанию, с джиттером и ограничением числа попыток;
— hard decline: остановка повторов, запрос на замену карты;
— insufficient funds: повтор только после окна вероятного пополнения;
— expired card: эскалация в self-service и уведомление до даты отзыва.

Не смешивайте retry платежного шлюза и dunning на уровне биллинга. Шлюзовый retry закрывает сетевые сбои, а dunning управляет жизненным циклом долга. Если оба слоя начнут повторять одно и то же событие без единого ключа операции, система превратится в генератор дублей и спорных списаний. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Хорошая схема: invoice создается один раз, попытки оплаты пишутся как отдельные события, а решение о следующем шаге принимает оркестратор по коду отказа, возрасту долга и истории попыток. Тогда можно безопасно остановить цикл, переключить метод оплаты или запустить уведомление без потери консистентности.

Стройте dunning как управляемый state machine, а не как cron с надеждой на лучшее: так вы снижаете revenue leakage и не сжигаете лояльность клиента на лишних повторах.