Привет, меня зовут Павел, я являюсь разработчиком в DD Planet. Сегодня хочу обсудить с вами тему - реализация собственного биллинг-сервиса.
В современном мире цифровых услуг и подписок часто возникает задача автоматизации этих процессов. Если требуется реализовать простой функционал оплаты по счетам или единовременные платежи, можно воспользоваться одним из множества доступных платежных шлюзов — их на российском рынке предостаточно. Однако при необходимости поддержки более сложных сценариев, таких как подписки, автопродление, виртуальные счета и гибкие тарифные планы, следует либо тщательно изучить существующие готовые решения, либо задуматься о разработке собственной системы. Как и в любом другом случае создания ПО — выбор между покупкой и созданием зависит от степени соответствия требованиям бизнеса.
Давайте разбираться, в каких случаях разработка кастомной биллинговой системы необходима.
Какие готовые системы сейчас есть на рынке?
На рынке существует множество решений, предназначенных для обработки платежей и базового управления подписками, однако они имеют определенные ограничения, которые делают их непригодными для реализации сложных сценариев.
1. Зарубежные биллинговые системы
Существуют международные решения, ориентированные на управление счетами и простой биллинг, например, InvoicePlane. Однако они не подходят для реализации сложных требований, связанных с подписками, виртуальными счетами и локальной спецификой. Основные недостатки:
- Отсутствие поддержки российских платежных систем, вроде Сбербанка, Тинькофф, QIWI, Яндекс.Деньги и Мир Pay
- Невозможность работы с виртуальными счетами и автопродлением подписок.
- Ограниченная интеграция с локальными банковскими API.
- Специфика российского законодательства. Например, Федеральный закон №54 требует применения онлайн-касс, а ФЗ-152 регламентирует хранение персональных данных только на территории Российской Федерации.
2. Российские биллинговые системы
- Биллинговые системы, которые используются в телекоммуникационных компаниях, операторах связи и интернет-провайдерах
для решения узко специфических задач — таких как учёт трафика, начисление абонентской платы и интеграция с оборудованием. Эти системы отличаются высокой сложностью, жёсткой архитектурой и плохой адаптируемостью к другим сферам. В digital-сервисах массового потребления такие решения неэффективны.
- 1С:Бухгалтерия
ориентирована на бухгалтерский учет и налоговую отчетность, но не предоставляет функционала для управления подписками и интеграции с платежными шлюзами.
- 1С-Битрикс24
Хотя платформа позволяет создавать интернет-магазины и частично управлять заказами, она не предназначена для реализации полноценного биллинга с автопродлениями, предоставления возможности продления подписок вручную, виртуальными счетами и сложной логикой тарифных планов, предусматривающей ежегодное повышение стоимости, автоматический перевод пользователей на новые тарифы. Любые расширенные функции требуют глубокой доработки, что делает её не масштабируемой.
Таким образом, ни одно из доступных решений не покрывает все потребности, связанные с гибким биллингом, что делает разработку собственного сервиса единственным эффективным вариантом.
Почему стоит разрабатывать собственный биллинг-сервис?
1. Сложная бизнес-логика, характерная для многих сервисов.
Например, компании могут сталкиваться с необходимостью реализации тарифных планов, предусматривающих ежегодное повышение стоимости, автоматический перевод пользователей на новые тарифы или предоставление возможности продления подписок как вручную, так и через автоплатежи.
2. Специфика российского законодательства.
Например, Федеральный закон №54 требует применения онлайн-касс, а ФЗ-152 регламентирует хранение персональных данных только на территории Российской Федерации. Эти аспекты могут не полностью поддерживаться внешними сервисами, что создаёт юридические и организационные риски.
3. Необходимость глубокой интеграции с российскими платежными системами.
Платформы вроде Сбербанка, Тинькофф, QIWI, Яндекс.Деньги и Мир Pay имеют свои особенности взаимодействия, и их полноценная поддержка в рамках одного интерфейса возможна лишь при наличии гибкой и масштабируемой системы.
4. Безопасность и контроль над данными.
При использовании сторонних решений компания передает часть ответственности за хранение и обработку финансовой информации третьим лицам. Это может быть неприемлемо в случае высоких требований к конфиденциальности и аудиту операций.
Какие основные задачи должна решать биллинговая система
Хранение баланса через виртуальные счета
Виртуальные счета — это важная часть современной биллинг-системы. Они позволяют пользователям хранить средства внутри сервиса и использовать их для оплаты подписок или тарифов, без необходимости каждый раз вводить данные карты или совершать новый платёж.
Каждый пользователь имеет свой виртуальный счёт, на котором хранится его баланс. Пополнение счёта возможно через банковский перевод или платежный шлюз. При покупке подписки или тарифа средства списываются именно с этого счёта. Если баланс недостаточен, система предлагает пополнить его перед оформлением заказа.
Администратор может просматривать историю операций, а также вручную начислять или списывать средства, например, при бонусных акциях или компенсациях. Для пользователя доступ к балансу и истории операций реализован через личный кабинет.
Гибкое управление тарифными планами
Одной из ключевых функций биллинг-системы является возможность изменения тарифного плана. Пользователь может перейти на более дорогой тариф, при этом учитываются неиспользованные средства по текущей подписке, рассчитывается сумма к доплате, и создаётся заказ на оплату разницы.
При переходе на новый тариф система:
Рассчитывает неиспользованный остаток по текущему тарифу.
Вычисляет стоимость нового тарифа.
Определяет сумму доплаты, если новая стоимость превышает остаток.
-
Предлагает пользователю произвести доплату:
С виртуального счёта (если баланс достаточен),
Через платежный шлюз (банковской картой).
Если средств недостаточно, система создаёт заказ на доплату, который можно оплатить через интерфейс сайта. При успешной оплате подписка обновляется, срок действия пересчитывается, и отправляется уведомление пользователю.
В случае неудачной оплаты система выполняет откат изменений: подписка остаётся на прежнем тарифе, а неиспользованный остаток возвращается к исходному значению.
Этот процесс реализован как state machine, что позволяет обеспечить целостность данных и корректную реакцию на ошибки. Все этапы операции фиксируются в системе для последующего аудита и анализа.
Из каких модулей должна состоять полноценная биллинговая система?
На основе вышеуказанных требований нами была разработана и внедрена система на стеке .NET, которая строится на основе микросервисной архитектуры и состоит из следующих компонентов:
1. Пользовательский интерфейс
1.1. Основной сайт (ASP.NET Core MVC/React)
Представляет собой пользовательский интерфейс, через который клиенты взаимодействуют с сервисом. Здесь они могут купить новую подписку (с привязанной карты, с новой карты или с виртуального счета), продлить существующую подписку, изменить тип подписки (только с доплатой), управлять автопродлением, просматривать историю заказов, привязать банковскую карту, отменить заказ.
1.2. Web сервисы (ASP.NET Core MVC/React)
Предоставляют пользователям некий функционал, для доступа к которому требуется наличие активной подписки
1.3. Сервис авторизации (ASP.NET Core Web API)
Инкапсулирует взаимодействие с сервисом подписок
2. Ядро системы (.NET 8)
2.1. Сервис обработки операций
Является ядром системы и представляет собой state-машину, где каждая транзакция проходит через строго определённые состояния: "Создан", "В обработке", "Оплачен", "Завершён", "Ошибка", "Отменён". Он обеспечивает последовательную обработку действий, исключая возможность параллельного выполнения конфликтующих операций и несогласованность данных. Например, если пользователь создал новый заказ, не отменив предыдущий, система корректно обработает ситуацию и предотвратит ошибки. Обеспечивается транзакционность операций, что особенно важно.
Сервис также устойчив к сбоям: если операция зависает на каком-либо этапе, то после устранения проблемы она продолжит выполнение. Например, если произошла ошибка при вызове платежного шлюза, система может повторять запрос или перейти в состояние "Повтор" и продолжить выполнение после восстановления внешней системы. Кроме того, он сохраняет историю операций для аудита и аналитики. Все финансовые операции записываются в журнал с указанием даты, типа операции, суммы, идентификатора пользователя и статуса. Это позволяет вести полноценный аудит и быстро находить причины спорных ситуаций.
2.2. Финансовый сервис
Отвечает за хранение баланса пользователей, управление виртуальными счетами и обработку операций пополнения и списания. Также обеспечивается поддержка российских банковских систем и соответствие налоговым требованиям.
2.3. Сервис активации подписки
Хранит информацию о текущем статусе подписок пользователей, включая срок действия и состояние. Он отвечает за активацию новых подписок и деактивацию истекших.
2.4. Сервис уведомлений
Отправляет email-сообщения пользователям о ключевых событиях (оплата, истечение подписки, изменение тарифа).
3. Платежные шлюзы
3.1. API взаимодействия с платежными шлюзами (ASP.NET Core Web API)
Интегрируется с внешними системами оплаты (Best2Pay, Ю.Касса) и обрабатывает callback. Чтобы избежать зависимости от конкретной реализации, вся работа с платежными системами изолирована, а остальные части системы работают с абстракциями.
4. Модуль администрирования (ASP.NET Core MVC/React)
4.1. Сервис управления тарифами
Содержит список доступных тарифов, включая историю изменений (например, ежегодное повышение цен). Он также управляет переводом пользователей на новые тарифы с уведомлением по электронной почте. Старые тарифы помечаются как неактуальные, а новые добавляются в систему.
4.2. Административная панель
Предоставляет аналитику по купленным подпискам, информацию об оплатах и состоянии виртуального счета каждого клиента. Она служит инструментом для оперативного управления системой и проведения аудита.
Заключение
Создание собственного биллинг-сервиса — это стратегическое решение, которое позволяет гибко адаптироваться к требованиям бизнеса, обеспечивать полный контроль над финансовыми процессами и соблюдение российского законодательства. Несмотря на наличие готовых решений, их ограниченная функциональность делает кастомную разработку оправданной, особенно для компаний с уникальными потребностями. В условиях, когда рынок еще не предложил универсальных решений, собственная разработка остаётся наиболее надёжным и масштабируемым вариантом.