<b>Биллинг нельзя тестировать «на живом»: как симулировать сбой шлюза без утечки денег</b>

<b>Биллинг нельзя тестировать «на живом»: как симулировать сбой шлюза без утечки денег</b>

Изоляция окружений — это не просто отдельная база и тестовый мерчант. Нужны раздельные ключи, отдельные очереди, собственные лимиты повторов и запрет на общие webhooks. Иначе тестовый charge может попасть в prod-реестр, а ретрай-воркер начнет догонять чужую транзакцию. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Для внешних шлюзов делайте не «мок, который всегда успешен», а набор поведенческих сценариев: таймаут до ответа, 5xx на авторизацию, частичный success без callback, дублирующий callback, потеря ACK, рассинхрон статуса. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: клиент уже получил отказ, а процессинг потом подтверждает платеж. Если нет строгой корреляции по payment_intent и журнала переходов статусов, появится revenue leakage.

Хорошая симуляция сбоев строится на fault injection в точках интеграции: прокси перед шлюзом, заглушка callback-канала, контролируемая задержка, подмена кодов ответа. Обязательно проверяйте:
— повторный запуск одной и той же операции;
— дедупликацию вебхуков;
— восстановление после падения воркера;
— согласованность ledger и ордера после retry.

Не смешивайте тестовые и боевые сигналы в одном контуре наблюдаемости: отдельные теги, отдельные алерты, отдельные SLA на обработку ошибок. Иначе вы будете лечить «ошибки теста» как инцидент по выручке.

Если сценарий нельзя воспроизвести в изолированном контуре, его нельзя считать протестированным.