Тестируйте биллинг так, будто шлюз уже рвёт сеть и шлёт дубли

Тестируйте биллинг так, будто шлюз уже рвёт сеть и шлёт дубли

Изоляция окружений в биллинге нужна не ради порядка, а чтобы не перепутать боевые деньги с тестовыми. Отдельные tenant’ы, отдельные ключи, отдельные очереди и отдельные таблицы ledger-логов — минимальный контур, где можно ломать поток оплаты без риска для выручки.

Самая частая ошибка — мокать шлюз «успешно/неуспешно» и считать тест завершённым. В реальности нужны сценарии с таймаутом после списания, повторной доставкой callback, потерей ответа на authorize и рассинхронизацией статусов между gateway и internal ledger. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Проверяйте не только happy path, но и поведение retry-loop: дубль invoice, повторный capture, partial refund, гонка между webhook и poller’ом, падение consumer’а после записи в outbox. У каждого внешнего шлюза должен быть симулятор с переключателями: network split, delayed ACK, malformed payload, duplicate event, out-of-order delivery.

Отдельно валидируйте границы консистентности: что считается источником истины, где фиксируется финансовое событие, когда разрешён компенсационный сценарий. Если тест не показывает, как система переживает расхождение статусов на минуту и на час, это не тест биллинга, а демонстрация интерфейса.

Стройте проверки вокруг инвариантов: одна финансовая операция — один результат в ledger, любой повтор безопасен, а потерянный callback не превращает выручку в ручной разбор.