Кастомный биллинг — любимый способ сжечь бюджет и потом чинить идемпотентность

Кастомный биллинг — любимый способ сжечь бюджет и потом чинить идемпотентность

Почти каждая команда приходит к одной и той же гениальной идее: «у нас особая модель, готовый биллинг не подходит». Потом начинается цирк:
• подписки с ручными продлениями и кривыми grace period
• инвойсы, которые нельзя повторно выставить без дублей
• холды, возвраты и частичные списания в одном аду
• вебхуки, которые «иногда теряются», то есть умирают без ретраев

Проблема не в UI и не в тарифах. Проблема в том, что биллинг — это не просто таблица с балансом. Это состояние, события, сверка, сеттлмент, спорные транзакции и бесконечные edge cases. Как только вы рисуете свой «простой» слой, он превращается в костыль на костыле и финтехом погоняет. Документация — это ложь, логи — истина.

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

Если очень хочется кастом, режьте его до минимума: свой catalog, своя бизнес-логика скидок, но не свой платежный мозг. Иначе через полгода вы обнаружите, что ваш мерчант забанен без объяснения причин, а бухгалтерия живет в Excel.