Как тестировать биллинг без утечки денег: изоляция сред и фейлы шлюзов

Как тестировать биллинг без утечки денег: изоляция сред и фейлы шлюзов

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

Для симуляции внешних шлюзов нужны не только мок-ответы 200/500. Нужны сценарии: таймаут на запросе авторизации, повтор доставки вебхука, расхождение между sync-ответом и async-событием, частичный фейл при capture/refund, недоступность idempotency-store. Именно здесь проверяется, выдержит ли система повторную попытку без двойного движения денег.

Тестовый контур должен уметь воспроизводить сетевой сплит, задержки, обрыв TCP-сессии и потерю ответа после фактической обработки операции. Полезно заранее проверять:
• идемпотентность на уровне API и consumer’ов
• транзакционную запись события до отправки во внешний мир
• дедупликацию входящих webhook delivery_id
• корректный dunning после временного отказа шлюза

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

Лучший тест для биллинга — тот, после которого в журнале можно доказать, почему денег стало ровно столько, сколько должно было стать.