Тест биллинга ломается не в коде, а на стыке сред, очередей и шлюзов

Тест биллинга ломается не в коде, а на стыке сред, очередей и шлюзов

Изоляция окружений в биллинге — это не «отдельная база для QA», а разрыв всех контуров, где может протечь деньги: токены, вебхуки, ретраи, ручные корректировки. Тестовый стенд должен исключать доступ к боевым payment credentials, но сохранять боевую логику: идемпотентные ключи, дедупликацию событий, транзакционную запись ledger.

Для симуляции внешних шлюзов полезны три класса отказов: • таймаут на запросе при уже списанных средствах; • дублирующий callback после успешной авторизации; • частичный отказ на capture/void, когда upstream ответил 5xx, а состояние в шлюзе уже изменилось. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Не ограничивайтесь «моками с happy path». Нужен fault-injection слой, который умеет: задерживать ответы, рвать соединение после отправки тела, возвращать противоречивые коды, эмулировать сетевой сплит и reorder сообщений в очереди. Отдельно проверяйте, как dunning и reconciliation ведут себя при повторной доставке одного и того же события.

Критерий успеха прост: после любого сбоя система должна либо безопасно повторить операцию, либо честно остановиться без двойного списания и без потери статуса. Если это не доказано тестом, в проде это станет revenue leakage.