Биллинг нельзя тестировать на “почти боевом” стенде: утечка денег начинается там

Биллинг нельзя тестировать на “почти боевом” стенде: утечка денег начинается там

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

Симуляция внешних шлюзов должна воспроизводить не только 200 OK, но и весь набор пограничных сценариев: timeout после списания, дубликат callback, частичный отказ, разрыв соединения, задержку ответа, несогласованность между авторизацией и capture. Для этого нужен stub, который умеет: • возвращать ошибку после фиксации операции • повторно слать одно и то же событие • менять порядок доставки сообщений.

Критично проверять идемпотентность на уровне всего контура, а не одного API-метода. Один и тот же payment_intent должен переживать повторный запрос, повторный callback и повторную обработку из очереди без двойного списания. Отдельно прогоняйте сценарии с падением БД между записью ledger и отправкой подтверждения: именно здесь рождается revenue leakage.

Хороший тестовый стенд для биллинга — это не песочница с “успешными” ответами, а модель враждебной среды. Если шлюз, очередь и БД не умеют ломаться предсказуемо, вы не тестируете систему оплаты — вы только имитируете ее работу.