После таймаута платёж нельзя просто назвать успешным или неуспешным. Ответ потерялся; денежный эффект мог уже произойти. Разберём учебный сценарий: агент должен оплатить один счёт один раз. Запрос отправлен, ответ API не пришёл, во внутреннем учёте стоит pending. Перед повтором я ищу доказательства для одного из трёх выводов: • ZERO: авторитетные для этой интеграции данные подтверждают, что зачисления не было. Повтор возможен по согласованным правилам и в рамках той же логической операции. • ONE: внешнее подтверждение показывает одно зачисление, хотя внутренний учёт ещё отстаёт. Второй платёж блокируем; учёт доводим до подтверждённого результата. • UNKNOWN: подтверждения ни нуля, ни одного эффекта нет. Останавливаем новое денежное действие и выясняем исход первого. Статус провайдера, webhook и запись в учёте отвечают на разные вопросы. Заранее договориться, какой источник решает вопрос повтора, так же важно, как написать тест на сам API. Открытый синтетический кейс: https://github.com/safal207/ContractGraph-QA/blob/main/docs/case-studies/AMBIGUOUS_PAYMENT_RECOVERY.md В нём нет клиентских данных и реальных переводов. Выводы относятся к учебной модели, а не к чужой платёжной системе. Первый пост серии: https://setka.ru/posts/01a0d44d-91b4-7881-bdac-0b9a1df79b20 Какой источник в вашей интеграции даёт право повторить платёж после таймаута?