Тестирование биллинга без изоляции окружений почти всегда заканчивается утечкой денег
Платежный контур нельзя проверять на «живых» данных и общих ключах: тест должен быть отделен от prod по всем слоям — merchant account, webhook endpoints, очереди, хранилище событий и алерты. Иначе вы тестируете не логику, а случайные побочные эффекты: двойные списания, ложные рефанды, расхождение статусов.
Для внешних шлюзов нужна симуляция не только успеха, но и отказов: таймауты, разрыв TCP-сессии, потеря callback, duplicate delivery, 5xx, partial capture, delayed settlement. Если мок умеет отвечать только 200 OK, вы не проверяете идемпотентность, dunning и восстановление после повторной доставки события.
Хорошая схема включает три слоя: • unit-тесты на маппинг статусов и расчет суммы; • контрактные тесты между биллингом и шлюзом; • интеграционные прогоны в песочнице с контролируемыми сбоями. Отдельно проверяйте race condition: два запроса на оплату, повторный webhook, отмена после авторизации, смена статуса при уже закрытом инвойсе.
Идемпотентный ключ, журнал исходящих запросов и детерминированный fault-injector дают больше пользы, чем десяток «успешных» прогонов. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.
Подписки: биллинг-лаб
@subscriptions_billing_lab_arb
Тестирование биллинга без изоляции окружений почти всегда заканчивается утечкой денег
Этот пост опубликован в Telegram-канале Подписки: биллинг-лаб. Подписаться можно по ссылке: @subscriptions_billing_lab_arb.