Кастомный биллинг почти всегда проваливается — и вы всё равно его напишете

Кастомный биллинг почти всегда проваливается — и вы всё равно его напишете

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

Самая мерзкая часть — биллинг не рисуется как CRUD. Там сразу всплывают:
• гонки между оплатой и отменой;
• рекурренты с retry-логикой и провалами на 3DS;
• prorate, паузы, паки, апгрейды, даунгрейды;
• сверка сеттлмента, refund, chargeback и ручных холдов.

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

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

Если вы всё-таки пишете свой биллинг — сначала опишите аварийные сценарии, а потом уже кнопки в админке.