eSellerate Plugin / Rolling Your Own Licensing System

Hi. I just installed the latest version of Xojo 2016 R2.1 on El Capitan (was previously using Xojo 2013 R3.3) and am testing all the old plugins still work.

I use eSellerate’s ewsPlugin.rbx for my licensing but when I try to compile the debugger doesn’t recognize the namespace of “eStore”.

Does the plugin no longer work? Mine is dated June 2013.

Does anyone have a newer version that works in the latest IDE and compiles for Cocoa etc?


Oh. That is REALLY bad. I have been using it for years for all my licensing.

But if that’s true and they will no longer update it … is there possibly a newer version of the plugin that exists that still works??

And if not is there another solution that not only allows license validation but also the embedded web store for in-app purchase?


Fastspring has support for AquaticPrime. Don’t know about in-app purchase. But you could ask them about this.

Even if the plugin does not get updated any more, it does not explain why you cannot even compile the app any more. That would be a regression bug in my book, at first sight.

Thanks, Beatrix. I will certainly check out FastSpring which I think could work for in-app purchase though I would prefer a license key system as opposed to a license file system (which I think Aquatic Prime is) on delivery since I have my own website store and it is easier for me to deliver serial numbers rather than license files.

Thomas: Maybe it’s because my new iMac is running Xojo in 64bit and the plugin is only 32 bit?

I would double check that you’ve installed the plugin. We’re slowly phasing out eSellerate and switching to FastSpring. But, I know the eSellerate plugin still works. Are you trying to do a 64 bit build?

Many years ago now they did a small update but I’m not sure it ever got released publicly. If you PM me with your email address I’ll send you the plugin I have (that works).

Bob: No I’m just trying to run it and have just checked it’s only targetting 32 bit. It just doesn’t recognize the namespace of “estore”. I closed and re-opened and the issue. Could it be a cache issue? I’ll PM you.

Update: Bob thankfully provided me with his copy of the plugin and that now works on my old iMac with Mavericks but after doing some investigating it seems my old plugin actually works on Windows 10 but not on El Capitan - both on a brand new iMac.

I installed a completely fresh installation of Xojo 2016 R2.1 with no other software installed.

I played around a bit with different versions of that old plugin and other plugins on both platforms and both iMacs and it’s beginning to feel like a Xojo error and not a plugin error because sometimes Xojo auto-complete recognizes the namespace but then fails to run with a “can’t find a type with this name error” as per this thread:

This even happens with an older version of Einhugar PictureEffects.rbx plugin.

Sometimes deleting the pre-compiled plugin cache works, sometimes it doesn’t, sometimes a complete reinstall works, sometimes it doesn’t. Has anyone spoken to Xojo about this or created a feedback ticket?

FWIW insisting on going with a payment provider that has dropped your development tool does not seem safe, or very reasonable. It may be time to let go, and embrace solutions that have a future.

Yes, Michel. I totally see your point and it is good advice.

I am seriously considering this but in reality the in-app payment provider part is not the issue for me, especially because I could switch to FastSpring for that or just sell directly from my web store.

The real issue for me is the serial number generation and the activation and validation system tied to it.

For me to roll my own system would be a mammoth task and very time consuming. And to go with another third-party provider feels like creating another headache for myself further down the line should the same thing happen again.

If I can get eSellerate to work for now then at least I can get my project completed and out there and then after that perhaps come up with my own system while I am not stressing about finishing a project and releasing it etc.

FWIW, we decided to go with LimeLM. ARGen 2.0 which was released this week uses it.

If the generation code is in PHP you can also consider Paddle.
Here is another thread:

The confusion as: For EU devs, Paddle seems to be the best option because you can set the main valuta to EU which is not possible with FastSpring. Otherwise FastSpring is the best option.

Thanks, Bob. Christoph.

In my opinion. If this is a new project; stop right now and move. It will be a lot harder in the future, especially as existing serial numbers will no longer work.

Consider building your serial number solution, either as a Xojo web app or PHP script. This way you unshackle yourself from a payment provider and change them when you need to.

I just want to explain why I said the above, as it’s a little harsh.

We signed up with eSellerate back in 2004 because of their plugin and we used them all the way until 2014, once Digital River bought eSellerate, they slowly gutted the resources and replaced the human employees with machines pre-programmed to say “No” to every request.

It took us years to move away, because we were tied into eSellerate’s serial number & activation system. The problem is that the only way to verify the eSellerate serial numbers is via their plugin, or to upload every single serial number issued to a server and have it verify there. It also means that we’d need to either use or build a solution that uses a similar format going forwards.

In the end we built our own solution in Xojo and used 1701 solutions to host our Xojo application, because we’re now in control of our own serial number/activation system we can do what we want going forwards.

On top of that we now have a centralized database of every sale, regardless of where the application is sold (except the app store, where we get squat). Basically every vendor has a unique SKU, when they make a sale, they hit our system suppling transaction information and our system returns them a serial number.

For most of our vendors we’re able to return a link which gets embedded into the customer’s receipt e-mail, meaning all the customer needs to do is to click the link in the e-mail to activate the product.

We only did this for new applications, this solution alone was a tremendous amount of work, but to change when a product is already established is even more work.

I understand the need to ship ASAP, but in my opinion, you’re much better off taking the time to invest in your own serial number/activation system now, rather than beating the dead horse that is eSellerate, costing you much much more time down the road (always when you don’t have the time too).

Since last year, I have been using my own license server hosted on 1701 as well for RubberViews Encrypted, and more recently for Fonts Manager, Check Printer and Check Writer when they are sold out of the MAS.

The back end payment processor being simply Paypal.

In Fonts Manager, I have in app purchase, and the app then fetches automatically the license from my server with HTTPSocket, so the app is activated automatically.

Like Sam, I have seen time and again Digital River take over friendly and efficient services, to turn them into trash. I promised myself never to depend on anybody but myself to tend the cash register.

Thanks, Sam and Michel. Sam, you are right, of course.

It’s just giving me a headache thinking about having to do this from scratch.

So if I do, here is what I think I need to achieve if I want to follow a similar process to eSellerate (which works for me):

  1. A way to generate a unique list of serials. I don’t want it based on an email or an order number. Like with eSellerate I just want to produce a list of serials with a specified prefix … based on a product/sku id perhaps. It will also need to use a fairly strong encryption algorithm so keygens can’t be created (too easily).

  2. A system in my app to validate the serial number.

  3. A system in my app to grab the user’s unique hardware ID and create an activation key based on that and the serial number that can then be stored in Windows registry or OS X support folder as an encrypted file etc.

  4. A system in my app to determine if the activation/serial has expired. For this I would either have to include that information in the serial key generation or call the web app.

  5. A web app and db (either written in Xojo or ASP.Net) that validates the activation key and ensures only n number of activations has been made, returning registraiton allowed or not alowed etc. I think this part is the easiest part. Although I believe the hardest part is determining whether the user’s machine id has changed or not. I know with eSellerate the problem a lot of the time was users making minor updates to their OS or upgrading from 10.5 to 10.6 etc and eSellerate would think it is a new machine.

  6. A way for users to manually activate their app without a direct internet connection. eSellerate handle this by making the user take their serial number and installation id to a web page (on a library computer or friend’s computer etc) and giving them an activation id to put back in their app.

  7. How to handle site licenses, for schools or classes etc?

  8. How to enable activation of a usb flash drive?

So there you have it. The road map. That’s why I’m starting to get stressed lol

Denise, give this article of mine a read:

If you want a unique list of serials then why do you need an algorithm? Make a random list, and if you want add an SKU in front of each. Voila.

Hand out the serials, validate against the list. Nobody can reverse engineer the list because there is no algorithm to reverse engineer.