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

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

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

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

Кастомный биллинг почти всегда тащит за собой зоопарк костылей: отдельные таблицы под холды, ручные ретраи, ночные джобы, которые «должны всё дожать», и админку, где оператор может случайно отменить не ту цепочку. Потом ещё добавьте PCI-зону, аудит прав, споры, chargeback-flow и внезапный edge case в рекуррентах. И вот у вас уже не продукт, а памятник техническому долгу.

Если очень хочется собирать биллинг самому, сначала ответьте на один вопрос: вы строите ядро бизнеса или будущий разбор полётов с поддержкой провайдера?

Смысл не в том, чтобы запретить кастом. Смысл в том, чтобы не тащить в самописку то, что должно жить в готовом биллинговом контуре: статусы, идемпотентность, retries, сверка, алерты. Всё остальное — отличный способ превратить продукт в вечную починку платежей.