User-flow built for you.
We provide a sophisticated licensing module, which is used also in Fireback, as well as to our clients who order backend projects with us. This module is very resilient, it can be used to sell and validate wide scenarios of software or physical goods.
In a nutshell it helps:
This module substitutes of few components that together give you the licensing module. In Fireback, you can
access it via
fireback licenses section.
First step to use licensing is to create a product inside licenses module. These products are not the same products that could be sold directly into an online shop and accept payment method. They only, contain the product name, such as 'MyDesktopApp' or 'MyCloudService', a private key and public which identifies it across the distributions.
Different version of the products can be a different product by themselves, requiring new purchase, or you can use the same private key for subsequent upgrades and users receive it for free.
For each product, you can define multiple plans. For example, "Free", "Pro", "Enterprise", and define price tag for it, including list of permissions, and some metadata if you would need it.
Plans do not hold private/public keys, they all use the same products key. It means same distribution of the software can activate multiple plans. You make multiple plans, for one single product
Now that you have defined your product and different possible plans inside, you can sell the software,
in different methods that we explore next. To elaborate, with
plans, you define what is
your software, and what level of accessing and features each type of user could have, but you
did not yet define how to sell it to people.
This module depends on plans, so you can generate offline keys to activate each plan for a user. Activation keys depend on plans not on the product, always being generated for plans.
Assume you want to distribute 10,000 copies of windows for Pro and Home users. You would generate 5,000 keys for home users, and 5,000 keys for Professional users, and sell it in different regions.
User would generate a license for themselves, using internet connection, with printed activation key, and getting their unique machine id.
In this method, no activation key is required, user would come to an online webpage, enter their computer
machine id, (You can read it with
fireback mid) and generate a license
for them. If the plan they choose has price, they need to make a payment, via available options in
We do not have a payment system or module at this moment, so if you want to sell the license key, instead of generating for free by getting user data, you need to create that logic yourself, and use Fireback http/grpc/cli tools to complete the action.
You can allow users to generate a license without a machine id, when you are validating it, software can skip the validate check for machine id. This is useful only when you do not care activation code to be published publicly. In such scenarios, add the buyer information in, so if they publish the key publicly they would be accountable.
For example in Fireback for Android, or Fireback for IOS, we do not ask the machine id. Simply it would make life of final users hard to activate a thirdparty libary in their app. We only generate a license to specific vendor and expect them to keep the value safe.
Now, all these actions are available both in HTTP, GRPC and CLI, we focus on CLI here but you can use the http endpoint instead as well.
First of all, we need to create a new product.