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

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

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

Кастомный биллинг почти всегда рождается из лени нормально описать доменную модель. Вместо этого лепят:
— ручные статусы вместо event-driven модели;
— пересчёт сумм по кривым округлениям;
— отдельную логику для подписок, холдов, возвратов и чарджбеков, которая не совпадает сама с собой.

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

Если уж вас не спасает здравый смысл и вы всё равно лезете в самописный биллинг, хотя бы заложите: явную модель состояний, replay-safe обработку событий, раздельный ledger, атомарность начислений и отмен, и отдельный слой для reconciliation. Без этого ваш «MVP» очень быстро станет уголовно дорогим экспериментом.

Кастомный биллинг почти никогда не экономит деньги — он просто откладывает счёт до первого инцидента. Идемпотентность или смерть.