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

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

Рекуррентная схема живет на трех опорах: корректный storage токенов, идемпотентный billing event и предсказуемый dunning-пайплайн. Если хотя бы одна из них дает сбой, вы получаете не просто decline, а расхождение между ledger, PSP и CRM.

Для отказов карт важно различать soft decline и hard decline. • soft: лимит, временная недоступность, недостаток средств — сюда уместны повторы по backoff и смена канала оплаты; • hard: утрата, блокировка, закрытый счет — тут автоматические повторы только ускоряют revenue leakage и раздражают клиента. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Dunning-стратегия должна быть событийной: триггер на код отказа, сегментация по age of debt, отдельные правила для первой и последующих попыток, заморозка доступа только после явного окна grace period. Полезно хранить не только статус попытки, но и причину, маршрут, версию правила и итоговый outcome, иначе разбор инцидентов превращается в археологию.

Надежная автоматизация всегда включает защиту от дублей, таймаутов шлюза и race condition между оплатой и отпиской. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: если retry не отделен от новой попытки, вы легко создадите двойное списание или ложный unpaid state.

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