Category: Tips on Using our Service

Unity is a powerful cross-platform game engine. Since it uses C# as the scripting language, we can easily integrate it with Cryptolens client library. In this post, we explain how you can add license key verification into a Unity game and briefly cover payment integration.

Adding software licensing

Download the binaries (please pick those without “System.Management”).

Adding payments

Once licensing is in place, the next step is to add payment integration. Since Cryptolens is cloud-based, you can easily integrate it with your own billing system or use our existing integrations with popular platforms such as Stripe and PayPal. You can read more about how this can be accomplished here.

Many times your customers may have either restricted internet access or no internet access at all. Although Cryptolens is a cloud-based licensing solution, you can still use it to protect offline devices. In this post, we cover three ways internet access can be restricted and how license key verification can be performed.

Periodic internet access

If your users are connected to the internet on a regular basis, we can cache the response from the “Activate” method each time we are able to contact the server. If, at some point, internet connection would not be present, we would fallback on a cached version of the license object.

When using this approach, it’s important to define how long time your users can be offline. There is a field called “SignDate” in the license key object, which is the time when the response was signed by the server (i.e. the last time you successfully called Activate). So, if you only want to allow your users to be offline for 30 days, you can compare the current date with the “SignDate”.

License server (re-routing)

If your users have certain devices that have no direct internet access, one option is to use a license server, which will re-route all requests through a server hosted by the user. Only the server has internet access.

There is currently a Windows version of the server, freely available on GitHub.

Air gap (no internet)

If the devices have no internet access at all, we can use a similar idea that was described in periodic internet access, with the only difference that we always fallback on the license file.

In Cryptolens, there are three ways you can create such a file:

In the dashboard

Next to each license key, there is a yellow button which can be used to create license files:

Floating licenses makes it easier for your customers to switch between machines that actively run your software, without having to deactivate them first. For instance, you can constrain the number of concurrent users to 10, but still allow the software to be installed on eg. 100 computers.

In Cryptolens, floating licensing works by letting your app to regularly poll the server to check if the number of concurrent users has been exceeded, which can be accomplished with the code snippet below:

Normally, if the app stops polling the server, that user will be automatically deactivated within the specified period of time. However, if you want to deactivate it instantly, you can use the code below:

Rhinoceros® (aka Rhino 3D) is a powerful computer graphics and CAD application. It’s also quite extensible as it allows developers to create their own plug-ins and add-ons. The aim of this post is to give you quick way of getting started with software licensing in your application, with focus on .NET.

One way of developing Rhino 3D applications is using Visual Studio. To add a simple key verification mechanism, only three steps are necessary:

Right click on your project in the Solution Explorer and click on Manage NuGet Packages.

On a mission to make software licensing more accessible, we have recently improved our Web API to make integrations with other services easier. For example, we have made it possible to return license keys as plain text, which many third party platforms require.

When selling software, there are two problems that need to be solved: payment processing and software licensing. Cryptolens core has always been the comprehensive licensing API. If you are using SendOwl or DPD, you can keep using them for payments and Cryptolens for software licensing.

A popular licensing model amongst software vendors is subscription-based licensing. It is generally seen as a smaller risk for the customer than traditional one-time payments (eg. which normally require a large commitment), but at the same time it provides recurring revenues for the software vendor.

Features

Recurring payments are implemented as a part of the customer portal. Thanks to this update, customers can not only manage their existing licenses but also subscribe for new ones.

Everything related to payments, plans and subscriptions is managed by Stripe, so if you’re already using Stripe, it’s quite easy to get started with the new recurring payments feature. If you do not have Stripe, it’s quite easy to get started. A tutorial can be found here.

In addition to recurring payments, the customer portal makes it possible to use user account authentication, described in the previous article.

Screenshots

Example when the customer has subscribed to a new plan:
The new license will show up on the home page of the customer:
Reviewing a license key and the subscription it is associated with:

A year ago we announced the ability to authenticate your customers inside the app using their credentials instead of using license keys. The key advantages are security (harder to crack properly secured account than a license key string) and time savings (customers can easily restore access to an account vs. restoring access to a lost license key). Today, we have released several changes to make the implementation of this much easier, as described under What’s new later in the article.

How Cryptolens approach is different

When we reviewed the way our competitors solve the problem of authenticating users, all of them used the simple solution of a method that takes in username and password and returns an access token. The problem with this approach is that the user needs to trust the client application, which can be compromised (eg. an attacker can create a similar app to trick the user to expose their login information). Even if the account itself may not pose high value, since users tend to reuse their passwords, it can serve as a gateway into their other accounts.

Instead of trusting the app, our approach puts trust in the web browser. The app will never receive the username or password. For extra-paranoid users, it is also possible to authenticate the request on a different machine.

To put the problem and our solution in simple terms, there is a concrete example from everyday life, namely when you pay using your credit card. The first approach we described is similar to paying using the terminal provided by the shop (i.e. you need to trust each store that their terminal does not record your card number and PIN). The second approach is similar to new types of payment methods where you need to scan a QR code and authorise the transaction on your phone. It is easier to trust your phone than the terminals provided by the store (and you will have to trust every single one of them).

What’s new

With the new release of Cryptolens.Licensing, implementation of account verification has become much simpler (as you can see later in the Getting started section). It now supports .NET Framework 4.0, 4.6 and .NET Standard 2.0. Moreover, we improved the backend to help automating account creation for customers (eg. portal link can now be obtained through Add Customer method).

Getting started

We have summarised the necessary steps to get started in this article. To sum up, two steps are necessary. First, you need to send an invite link to your customer (which can be automated). The second step is to include the following code in your application.

Many software vendors nowadays move away from one-time payments to other licensing models. One such example is the usage-based model. By doing so helps lowering the barrier of entry for new customers, as they no longer need to commit to the product long term, which is usually the case with one-time payments. If you already have a subscription model, supporting usage-based payments can help you to monetise a group of users who would otherwise not buy the product.

Getting started

In Cryptolens, usage-based licensing can be implemented using data objects, aka custom variables. We can use these variables to record how often features are used and keep track of any usage credits that a customer has purchased. There are two ways of billing customers:

Upfrontpayment: customers need to purchase usage credits in advance.

Based on actual usage: customers pay for the actual usage in the end of the billing period.

Charging based on actual usage

If you choose to charge your customers based on actual usage, we can simply use the code below:

Upfront payments

If you instead want to charge your users upfront, we need to create the data objects when creating the license. If you are using payment forms, we can set up two requests, one creating a new license and another creating a new data object (inspired by this tutorial), as the result from key creation will be “piped” into data object creation request. You can then have another payment form that allows users to refill their credits, in which case the custom field can be used.

You can use the code below to verify if the limit was reached inside your application: