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

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

Если карта отклонилась, система должна не «пытаться еще раз», а определить класс отказа: временный, жесткий, антифрод, недостаток средств, истекший срок, неверный CVV. Без этой развилки dunning превращается в шум: вы повторяете заведомо бесполезные попытки и теряете выручку из-за лишней нагрузки на шлюз и раздражения клиента.

Базовая схема проста:
— фиксируйте исход авторизации и код ответа в неизменяемом журнале;
— делайте повтор только через идемпотентный ключ, чтобы не создать дубль;
— разделяйте retry policy для soft decline и hard decline;
— задавайте backoff с ограничением числа попыток и «окном тишины» после серии отказов.

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

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