Definova — RPA Marketplace

Обзор

Definova — RPA-маркетплейс, где разработчики автоматизаций публикуют свои приложения, а пользователи покупают и запускают их через единый кабинет с внутренней валютой (AET). Это не просто витрина: в маркетплейс встроены биллинг, шесть моделей монетизации и REST API, через который любое приложение — бот, парсер, SaaS или Telegram-сервис — может списывать оплату с баланса пользователя.

Проблема

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

Решение

Я спроектировал платформу вокруг двух ролей и одного кошелька. Пользователь пополняет баланс в AET и тратит его на приложения; разработчик публикует приложение, выбирает модель монетизации и получает доход на тот же баланс. Каталог с фильтрами по категории, типу монетизации, способу запуска, платформе и ОС связывает спрос и предложение, а REST API закрывает главную боль — встраивание оплаты прямо в код приложения, без собственного биллинга.

Модели монетизации

При публикации разработчик выбирает, как приложение зарабатывает:

• Бесплатно — для лидогенерации и портфолио
• Единоразовая продажа — покупка приложения навсегда
• Ежедневная подписка — списание фиксированной цены за день использования
• Оплата в USDT — продажа за криптовалюту
• % с дохода — платформа берёт долю от заработка приложения
• Партнёрское приложение — монетизация по партнёрской модели

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

API для разработчиков

REST API превращает маркетплейс в платёжный слой для чужих приложений. Аутентификация — по API Key и идентификатору Merchant ID с подписью Sign в заголовках запроса; набор ключей зависит от роли интеграции. Через API приложение проверяет баланс, списывает оплату по выбранной модели и получает статистику доходов. Это полезно тем, кто продаёт BAS-приложения, цифровые товары, Telegram-ботов и веб-сервисы и хочет быстро встроить готовую монетизацию вместо разработки биллинга с нуля.

Возможности

• Каталог приложений с фильтрами по категории, типу монетизации, способу запуска, платформе и ОС
• Карточка приложения: описание, демо-видео работы, технические детали, отзывы и жалобы
• Кабинет пользователя: баланс в AET, динамика расходов, дневной лимит трат и API-ключи
• Панель разработчика: статистика установок и дохода, рейтинги, топ приложений
• Форма публикации с медиа, ссылками на скачивание/инструкцию и выбором модели монетизации
• Пополнение баланса картой, история покупок и расходов
• REST API для встраивания оплат с аутентификацией по ключу, Merchant ID и подписи
• Двуязычный интерфейс (RU/EN) и роли пользователя, разработчика и администратора

Процесс разработки

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

Результаты

• Сквозной поток «пополнение → покупка → доход разработчика» работает на одном балансе
• Шесть моделей монетизации покрывают разовые продажи, подписки и доход с процента
• API позволяет встроить оплату в приложение без собственного биллинга
• Единая история расходов и лимиты дают пользователю контроль над тратами

Выводы

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