Кастомный биллинг — это не продукт, а коллекция будущих инцидентов

Кастомный биллинг — это не продукт, а коллекция будущих инцидентов

Почти каждый бизнес приходит с фантазией: «у нас нестандартные тарифы, значит, готовый биллинг не подходит». Потом начинается любимый жанр: свои статусы, свои переходы, свои исключения. Идемпотентность? Потом. Рекурренты? Как-нибудь. Холды и частичные списания? «Разберём на спринте».

Проблема не в коде, а в том, что биллинг — это не таблица тарифов. Это машина состояний, где ломаются: — дубли из-за кривых ретраев; — расхождение между ledger и фактическим списанием; — вебхуки, которые приходят не тогда, когда надо, а когда им вздумается; — возвраты, которые внезапно требуют обратного прохода по всей цепочке.

Дальше начинается магия. Бизнес просит «сделать проще», разработка вырезает проверки, поддержка ловит двойные списания, а финансы внезапно обнаруживают, что сеттлмент не бьётся с внутренним учётом. Документация — это ложь, логи — истина. И в логах обычно видно одно: кастомный биллинг уже живёт своей жизнью и давно не совпадает с тем, что рисовали на схеме.

Правило простое: если вам хочется написать биллинг с нуля, сначала опишите все статусы, все переходы, все ретраи, все отмены и все edge cases. Потом добавьте туда аудит, reconciliation и ручной саппорт. Если после этого желание не прошло — поздравляю, вы всё ещё не поняли, насколько это больно.

Костыль на костыле и финтехом погоняет: кастомный биллинг почти всегда дешевле только на презентации.