Definova — RPA Marketplace

Overview

Definova is an RPA marketplace where automation developers publish their apps and users buy and run them through a single dashboard backed by an in-platform currency (AET). It’s more than a storefront: billing, six monetization models and a REST API are built in, so any app — a bot, a parser, a SaaS product or a Telegram service — can charge against a user’s balance.

Problem

The automation community sells scripts through forums and DMs: no catalog, no transparent payments and no monetization beyond “buy it once.” A developer who wants to charge per run, per subscription or as a revenue share has to build their own billing from scratch. Users, in turn, have no place to compare apps, see ratings and pay from a single wallet. The market exists — the infrastructure for flexible monetization does not.

Solution

I designed the platform around two roles and one wallet. Users top up an AET balance and spend it on apps; developers publish an app, choose a monetization model and earn revenue into the same balance. A catalog with filters by category, monetization type, run method, platform and OS connects supply and demand, while a REST API solves the core pain — embedding payment directly into an app’s code without building any billing.

Monetization Models

When publishing, a developer chooses how the app earns:

• Free — for lead generation and portfolio pieces
• One-time sale — buy the app outright
• Daily subscription — a fixed charge per day of use
• USDT payment — sell for crypto
• Revenue share — the platform takes a cut of what the app earns
• Partner app — monetization via a partner model

Price and type are set in a single form, and all charges flow through one shared wallet, so a user sees a unified spending history no matter how many apps they run.

Developer API

The REST API turns the marketplace into a payment layer for third-party apps. Authentication uses an API Key and a Merchant ID with a Sign signature in the request headers; the set of keys depends on the integration role. Through the API an app checks the balance, charges by its chosen model and pulls revenue stats. It’s built for people selling BAS apps, digital goods, Telegram bots and web services who want to drop in ready-made monetization instead of building billing from zero.

Features

• App catalog with filters by category, monetization type, run method, platform and OS
• App detail page: description, demo video, technical details, reviews and complaints
• User dashboard: AET balance, spending trend, daily spend limit and API keys
• Developer panel: install and revenue stats, ratings, top apps
• Publishing form with media, download/instruction links and monetization model selection
• Card-based balance top-up, purchase and expense history
• REST API for embedding payments with key, Merchant ID and signature auth
• Bilingual UI (RU/EN) and user, developer and admin roles

Development Process

The wallet was the heart of the platform: until charges, top-ups and payouts reconciled to the cent on a single balance, nothing else mattered. So the MVP started with billing and the user dashboard, then the developer panel with monetization models, and only then the public API that exposed the same payment logic to third-party apps. Catalog filters and the “Getting started” block were added from early developers’ feedback.

Results

• An end-to-end “top up → buy → developer earns” flow runs on one balance
• Six monetization models cover one-time sales, subscriptions and revenue share
• The API lets developers embed payments into an app without building billing
• A unified expense history and limits give users control over spending

What Was Learned

A monetized marketplace is reliable billing first and a storefront second. Flexible payment models are worthless if the wallet doesn’t reconcile; conversely, once charges became predictable, adding a new monetization model or exposing it through the API was a matter of configuration, not a rewrite.