Взять готовое или написать свое? Вечный спор в любом бизнесе, который остро встает при выборе буквально чего угодно. И биллинга в частности.

На старте идея написать свою биллинговую систему может показаться невероятно привлекательной. Ведь это просто, быстро и дешевле — у нас и так есть команда разработчиков, зачем платить вендору? К тому же, порой очень хочется получить ту самую гибкость, которой, как кажется, на первый взгляд, нет в коробочных решениях.

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

Почему вообще возникают мысли о самописном биллинге

Обычно в пользу внутренней разработки выступают четыре главных аргумента:

• Финансовый триггер

Стоимость текущего коробочного решения возрастает или меняются условия лицензирования. С точки зрения краткосрочной экономики оплата внешнего вендора начинает казаться нецелесообразной, особенно при наличии свободных ресурсов внутри компании.

• Ограничения кастомизации

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

• Продуктовый бэклог вендора

Вендор развивает платформу в интересах сотен клиентов, поэтому какие-либо нишевые и специфические фичи, важные для конкретной компании, могут ждать реализации довольно долго.

• Переоценка собственных сил

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

А как все обстоит на самом деле?

Именно биллинг принимает на себя первый удар при любых изменениях — как внутри продукта, так и со стороны законодательства и регуляторов. Почти сразу после релиза собственного решения команда упирается в 3 пласта задач.

Развитие тарифной сетки и маркетинговых инструментов

На старте, пока у компании есть пара-тройка актуальных тарифов с простой оплатой (например, фиксированная подписка или плата за выделенные ресурсы раз в месяц) реализация собственного биллинга действительно не составит труда. 

Однако по мере роста и развития бизнеса неизбежно потребуется внедрение дополнительных схем и механих — промокодов, прогрессивных скидок и реферальных бонусов для стимуляции продаж. Будет меняться и тарифная сетка, а простая ежемесячная оплата превратится в сложную матрицу динамического ценообразования, где нужно с высокой точностью высчитывать стоимость каждого отдельного ресурса, условия его предоставления и лимиты. 

Нередко именно на этом этапе разработка собственного решения начинает усложняться и замедляться. Ведь в случае с самописным биллингом придется тратить немало ресурсов на проектирование логики и непосредственную разработку любой нужной фичи. В коммерческих платформах — например, в том же BILLmanager — этот функционал изначально заложен в ядро системы, так как вендор развивает его на основе опыта сотен разных клиентов.

Фискализация и налоговый учет

Вместо оптимизации архитектуры приходится сдвигать приоритеты в сторону регуляторных и учетных задач:

• Финансовая отчетность — выгрузка данных для налогового учета, обновление форм закрывающих документов под меняющиеся нормы и контроль рекуррентных списаний.

• Требования 54-ФЗ — интеграция с онлайн-кассами, формирование номенклатуры в чеках и корректная обработка сценариев с частичными возвратами или авансами.

• Масштабирование структуры — разделение финансовых потоков и учет разных налоговых режимов при появлении новых юридических лиц.

Каждое изменение формата фискальных документов или налоговых ставок принудительно попадает в план внутренней разработки с наивысшим приоритетом. В случае с коробкой регуляторные риски и рутинная поддержка ложатся на вендора — в частности, мы как разработчики BILLmanager отслеживаем изменения в законодательстве и стараемся выпускать такие важные обновления заблаговременно — к началу действия новых законодательных норм — чтобы у пользователей был запас времени на адаптацию процессов.

Скрытая стоимость владения

Со временем любая команда, решившая написать собственное финансовое ядро, упирается в архитектурные ограничения выбранного решения. На старте кодовая база может действительно выглядеть компактно, но по мере роста проекта она обрастает многочисленными условиями и исключениями. Корректная обработка часовых поясов при рекуррентных списаниях, кастомные промокоды, изменение тарифных планов задним числом и частичные возвраты усложняют схему базы данных и делают бизнес-логику трудноподдерживаемой.

В этот момент проявляется реальная стоимость владения (TCO) собственным решением, которую редко точно рассчитывают на этапе проектирования:

• Прямые затраты на разработку и поддержку. Первоначальная оценка сменяется необходимостью выделять отдельных разработчиков на постоянной основе. Эти специалисты заняты обслуживанием транзакционной логики вместо создания функций основного продукта.

• Затраты на поддержку и обновление интеграций. Платежные системы и онлайн-кассы регулярно обновляют свои API и форматы данных, а продукты и сервисы, с помощью которых предоставляются услуги клиентам, постоянно развиваются. Все эти изменения необходимо своевременно учитывать в собственном решении.

• Расходы на сопутствующий софт. Полноценный биллинг — это не только списание денег, но и обслуживание клиентов. Готовые коммерческие платформы обычно сразу включают в себя встроенную систему поддержки. В случае с самописным решением вам придется либо делать свою тикетницу с нуля, либо покупать сторонний сервис и тратить ресурсы на его интеграцию.

• Высокая цена ошибок в расчетах. Погрешности округления, повторные списания или неверный расчет пропорциональной оплаты при смене тарифа могут в итоге приводить к прямым финансовым потерям и оттоку клиентов.

• Замедление разработки основного продукта. Когда бизнесу потребуется запустить новую маркетинговую акцию, скидку или кастомный тариф, может возникнуть ситуация, при которой разработчики будут вынуждены переключиться с создания фич основного продукта на развитие и модификацию платежной логики. В итоге развитие сервиса, который приносит компании реальную ценность, встанет на паузу ради доработки чисто внутреннего, обслуживающего инструмента.

В итоге совокупная стоимость владения самописным биллингом начинает превышать цену лицензии коробочного продукта. А когда решение окончательно перестает справляться с нагрузкой или требованиями бизнеса или комплаенса, менеджмент принимает решение перейти на коммерческую платформу. Однако из-за высокой связности кода и бизнес-логики быстрая миграция не всегда становится возможной из-за сложностей в переносе истории транзакций, профилей клиентов и актуальных балансов в зрелом бизнесе.

Когда действительно необходимо писать собственный биллинг

Тем не менее, существуют сценарии, в которых создание собственного биллинга коммерчески или технически оправдано. 

• Уникальная бизнес-модель и специфические тарифные сетки

Самый очевидный кейс — уникальная бизнес-логика и нестандартные модели тарификации, которые технически невозможно уложить в архитектуру ни одного из существующих на рынке сервисов. 

• Глубокая интеграция с внутренними системами

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

Иными словами, если ваш бизнес не является финтех-платформой, а модель тарификации не представляет собой главное рыночное ноу-хау, попытка написать свой биллинг с высокой долей вероятности обернется для вас высокими затратами — не только финансовых, но и человеческих ресурсов. Даже если вы предоставляете уникальный кастомный сервис, интеграция с которым изначально не добавлена в коробочное решение, развитое API BILLmanager позволяет быстро создать надежную интеграцию с любым внешним продуктом. Задачи по кастомизации внешнего вида и личного кабинета при этом закрываются через встроенные функции брендирования и White Label, которые мы постоянно расширяем.

Такой подход позволяет изолировать сложное финансовое ядро во внешней коммерческой системе, сохранить фокус бэкендеров на развитии профильного продукта компании и гарантированно избежать жесткого архитектурного тупика.