Building Licensing server for per-seat licensing model - database design and payment aspects

Question

Hi,

sorry for lengthy post, and thanks in advance for reading through it.

I am developing software that should use licensing model which is I believe similar to per-seat licensing:

• There is a central licensing server, which approves/denies licenses
• Central server allows customers to purchase certain number of licenses at any given moment (and then they become customers)
• Licenses are of lease-type, meaning that they have a specific duration (number of months or even years)
• Customers should be able to change number of purchased licenses at any time, doesn't matter if it means increasing or decreasing number of active licenses (say, they need few licenses more or less due to their specific circumstances)
• Customers need to be able to renew licenses

Since I'm still stuck in a design phase, and my goal is to produce a solution that is very flexible; that's why feature list above is perhaps very complex. I would greatly appreciate advices on how to solve several problems that this design introduce. As I wrote in title, aspects that I am interested in right now are database design and payment processing (to some extent).

Lets assume that customer has purchased certain number of licenses for duration of 6 months. This event would be processed like this:

1. customer can see the total price, which he pays.
2. database record is made about this specific payment.
3. database record is made to grant the customer rights to use specific number of licenses.
4. when software at customers side asks for number of available licenses, database answers something like: XYZ licenses, expiring on ABC date.

Then, 3 months later (exact time is not important here, but it's important to note that it's not near the end of previous duration of 6 months), customer decides to purchase few more licenses, to fulfill growing needs. Now, I am having troubles thinking of how to process that kind of event.

Is it better approach to...

a) keep track of each purchase (and license records) independently, allow client to purchase completely new set of licenses, and then let him take care of multiple licenses, their expiration dates, renewing each one independently from the rest (and thus having ability to cancel renewal of each one whenever he desires), and when client software asks how many licenses are available, to aggregate all available, valid licenses...

...or...

b) merge licenses, tell customer that he already has XYZ active licenses, and that in order to change number of active licenses, he would have to pay adjusted price that depends on how much time remains until active licenses expire, and if he agrees, new licenses are merged in database, but separate purchase record is made anyway in database to keep track of purchases; when client software asks about available licenses, it's simple matter of answering back whatever database says about merged license.

Approach a) is very simple to understand for customers, but is equally hard to maintain once customer starts purchasing additional licenses. Also, I have no idea how would I make it possible for clients to decrease number of licenses (see last point, below).

Approach b) is sort of complex in terms of determining how to increase (or decrease) number of licenses and merging changes with active license, but is very simple from that point onwards, because client has effectively only one license to renew.

Then, once again, client decides to change number of licenses, but this time, his business is declining and doesn't need that many licenses. This kind of event has got me lost completely. Should I allow client to "release" some of active licenses, convert that into value (say, virtual currency), which customer can later use to re-purchase another set of licenses, to renew existing ones, etc...?

Many thanks to everyone who reads through this and decides to help!

Answer 1

It is probably gong to make more sense for the customer, simplify their future renewals, and make your management simpler if you insist that the renewal interval remains the same for all licenses. When they ask to buy more you could say: "You can either purchase 'n' more licenses which will be valid to the end of your current subscription period at a pro-rated price (e.g. half if they are halfway through their subscription period), or you can choose to renew your subscription for your existing licenses now, and add these new licenses to your pool (so, for example, they would pay for the full subscription period for the sum of the old and new licenses, plus the pro-rated fee for the new licenses to the end of the current period; maybe you package this with a discount as an encouragement to extend now).

Either approach - or indeed the other option you outlined above - is already supported by the Orion license server we offer. If you are open to considering buying a working, documented system instead of embarking on your own development project do please give us a look.

Dominic Haigh Agilis Software www.agilis-sw.com