Кастомный биллинг — это не гибкость, а билет в ад поддержки и сверок

Кастомный биллинг — это не гибкость, а билет в ад поддержки и сверок

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

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

Ещё хуже другое: свой биллинг быстро становится кладбищем бизнес-логики. Каждая новая акция, подписка, промо-окно или split payment добавляет ещё один костыль. Через полгода никто не понимает, почему платёж прошёл, но доступ не открылся. Через год ваш мерчант забанен без объяснения причин, а команда пишет «быстрый хотфикс» в пятницу вечером 😈

Если очень чешется сделать кастом — хотя бы отделяйте оркестрацию от расчёта, храните state machine явно, не доверяйте синхронному ответу провайдера и закладывайте ручную сверку как обязательный процесс. Иначе вы не строите billing engine, вы собираете инциденты в красивой обёртке.

Вывод простой: свой биллинг делают не потому, что он нужен, а потому что недооценили объём боли. Идемпотентность или смерть.