Биллинг нельзя тестировать на “почти проде”: изоляция и фолт-инъекция решают

Биллинг нельзя тестировать на “почти проде”: изоляция и фолт-инъекция решают

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

Минимальная изоляция включает:
— отдельные merchant/account ids;
— раздельные webhook-эндпоинты и секреты;
— собственные idempotency keys и sequence numbers;
— запрет на доступ к боевым customer objects и recurring jobs.

Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы. Проверяйте не только happy path, но и дубли запросов, задержанные callback’и, out-of-order события, частичные списания и разрыв между авторизацией и capture. Особенно опасны кейсы, где шлюз ответил 200, но downstream не сохранил транзакцию: именно там рождается revenue leakage.

Симуляция сбоев должна быть управляемой: задержка ответа, timeout на шлюзе, TCP reset, битый webhook payload, повторная доставка одного и того же события, рассинхрон статусов между провайдером и вашей БД. Отдельно прогоняйте сценарий сетевого сплита: клиент уже получил invoice, а ваш reconciliation-джоб еще не видит подтверждение оплаты.

Финальный критерий прост: если тест не умеет воспроизводить потерю, дубль и рассинхрон, он бесполезен для биллинга. Лучший контур — тот, где любая ошибка внешнего шлюза превращается в предсказуемый branch логики, а не в ручную разборку инцидента.