TrialPay Integration with IPN.NET


Posted by Cynic | Posted in C#, DotNetNuke, Online Marketing, Software, Solutions to Problems | Posted on 22-09-2011

Tags: , ,

TrialPayI’m slowly closing in on being able to release the new Photo Resizer Social Edition. It will feature 1-click photo uploading to Facebook, Flickr, and TwitPic/Twitter, but all that has been the easy stuff so far. The licensing and marketing side of it is where the real work is.

Building on how I integrated ILS and IPN.NET with DotNetNuke, I’m now adding in TrialPay to the licensing process. For those that don’t know TrialPay, it’s a fantastic idea from Alex Rampell, Terry Angelos and Eddie Lim who founded TrialPay in 2006. I first met them at SIC 2006 in Denver. (I think that was the last CoffeeCup party there as well.) I’d blogged about it here, and shortly thereafter got an email from Alex joking about how he was pissed that I was beating them in the search engines for “trialpay”. We got a kick out of that.

Anyways, TrialPay lets you present users with an option to purchase some product or service, and in return, give them a license for your software for free. It’s good for everyone all the way around. I’ve recommended it to other developers, and they’ve come back with positive stories about increased revenues.

TrialPay has a very good interface to integrate with different styles of licensing systems. As I’ve already got IPN.NET and ILS in place, it’s just a matter of hammering things around a bit to get things working right.

My last round of DNN/ILS/IPN.NET integration is running smoothly, and adding in TrialPay has had noadditional  impact on DNN, though it does have a significant impact on IPN.NET.

While I’ve tried to minimize the impact, I also need to spend my time wisely. As such, there’s a higher impact on IPN.NET than I would really like, but the time it has taken to do it wasn’t very much.

To integrate TrialPay with IPN.NET, there are a few things that need to be done. All of the integration-specific changes and set up from the TrialPay side are done on the “Product Delivery” page in the product configuration:

TrialPay Product Setup MenuOnce there, under “Activation Method”, choose the “Provide a unique key that I will generate” option. You need to have your IPN.NET URL ready for that as well.

TrialPay Activation Method - Unique Key I Generate

Most of the other settings are pretty straight forward, but you’ll want to make certain that you set up the parameters that TrialPay will POST to your IPN.NET instance. (Don’t use GET. That’s just a bad idea.) So, for example, you could have these parameters:


TrialPay gives you a huge amount of freedom to set up whatever you like. However, it is CRUCIAL that you pass a value for your item number (item_number) back to yourself. It MUST be the same as an existing item_number that’s already set up in IPN.NET. This will be the same as the item_number that you enter into License Tracker. (See my article on entering large numbers of products into License Tracker.)

The item_number is used by IPN.NET to create licenses, so, it’s just kind of a little bit important. ­čśë However, see below for how to quickly hack this with the testing tool…

Once you have that set up, you can then move on to customizing your IPN.NET installation. You can get away with only 4 real changes:

  1. Add in a string member variable to contain the key for TrialPay
  2. Add in a ProcessPurchaseItem > ProcessTrialPayItem method
  3. Add in a SendNotificationEmail >SendTrialPayNotificationEmail method
  4. Add in some custom logic for TrialPay at the top of the Page_load method

IPN.NET has a huge amount of error checking, and even posts back to PayPal to verify license purchases. Now, you can work with this, but it’s a significant amount of effort, and has a massive impact on IPN.NET, so it might not be worth it to you. Instead, you can filter for TrialPay POSTs and then just run some custom logic and end there.

You can do that with minimal impact by adding that to the top of the Page_load event in IPN.NET. You can simply use an IpnData object to pull in the POST variables, but you’ll need to modify the IpnData class if you don’t use the same variable names. As such, it’s simpler to use the IPN.NET/PayPal variable in TrialPay, as you can see above.

The “ipn” IpnData variable is a member variable, so it has a global scope in Default.aspx.cs. You should set it something like this in the Page_load event:

ipn = new IpnData(Request.Form);

That then lets you reuse the “ipn” variable for TrialPay, and alleviates any need to rewrite basically everything.

Now, you’ll probably want to rewrite/tweak the ProcessPurchaseItem() and the┬áSendNotificationEmail() methods. The “log” variable is a member variable as well, and you’ll need to do a lot of rewriting if you want to use it. If you want to work with License Tracker for TrialPay purchases, then you’ll need to do a lot of that work as the log creates a logfile that gets emailed to you in IPN.NET normally. However, if you cut out the logging, it won’t get created, and you won’t be able to import it from Outlook with License Tracker. Yuck. That’s pretty complicated. So… Might as well take the quick and easy route…

Notably, IPN.NET does a POST back to PayPal for verification, and you can’t do that while using TrialPay. This happens in the Page_load event just before the┬áProcessPayment() method call. The┬áProcessPayment() call contains the┬áProcessShoppingCartItems() and ProcessSinglePurchaseItem() method calls, which is where the actual licensing “work” gets done.

For TrialPay, I’m only interested in selling 1 license at a time, so I’m only concerned with the┬áProcessSinglePurchaseItem() method. It contains the┬áProcessPurchaseItem() method call, which as I’ve mentioned above, I’ve tweaked for TrialPay.

So, I’ve simply created a┬áProcessTrialPayItem() and a┬áSendTrialPayNotificationEmail() method from the 2 mentioned above, then tweaked them for what I need, i.e. to send people their licenses and send me a quick and dirty email notification. You can open up the source code to see inside them. From what I’ve written here, it should be very simple for you to modify them similarly to what I have, or perhaps even more extensively, depending on your requirements.

Modifications for the┬áProcessTrialPayItem() method basically boil down to commenting out the log calls, and the tweaks I’d previously made to integrate IPN.NET into DNN. Actually, this entire block can be deleted:

if (item.IsUpgrade)
{ … }
else if (!CartHasPrerequisiteItems(item))
{ … }
else if (BlockCustomerEmail())
{ … }

However, it doesn’t matter whether you delete it or not. None of those conditions will ever be satisfied except possible the BlockCustomerEmail() method call. However, there I would strongly recommend either deleting the entire contents of that file, or very carefully editing it. If you’re selling consumer level or professional level software, the chances are VERY high that many of your customers will have email address that would get blocked there. Not good.

Modifications for the┬áSendTrialPayNotificationEmail() method boil down to nothing. There’s a log check to see if it is null, but that can stay in.

Now, if you want to hack things up while testing with the Infralution IPN Test Tool, just set the product item_number something like this:

item.ItemNumber = “ACME123”;

You can add in some logic that draws on data from the TrialPay POST (if you have more than 1 product pointing to the same IPN.NET instance), but that’s not very hard to figure out. You just need to keep it straight with the Infralution IPN Testing Tool.

The issue there is that you can end up with “item_number1” when you’re expecting “item_number”. It can be remedied, but I’m quite frankly too busy/lazy to get on top of that one when I have zero reason to right now.

I can’t post much code as that is not a part of what I am allowed to do according to my Infralution source code license, but I can post a little bit. The following is some very brief logic for what you want to stick up at the top of your IPN.NET Page_load event:

// If we have a Trial Pay sale...
if (isTrialPay)
    // Recycle the "ipn" member variable:
    ipn = new IpnData(Request.Form);
    // Create an item for the TrialPay "purchase"
    PurchaseItem tpItem = new PurchaseItem();
    // Hack/fix the item number for the InfralutionIPN Testing Tool
    tpItem.ItemNumber = "ACME123"; // Used below
    // Now, get the item from your existing IPN.NET settings:
    tpItem = GetPurchaseItem(tpItem.ItemNumber);
    // Call the tweaked method to process the "purchase":
    ProcessTrialPayItem(tpItem, 1);
    // Send the license email to the customer:
    // Clear the HTML body response but not the headers (should be 200):
    // You must return the key to TrialPay in the HTML body.
    // "tpKeys" is a member variable that you set in the ProcessTrialPayItem() method above:
    // HTML markup is not valid for the response to TrialPay, so end the response and send it back:

Now, you’ll need to figure out how you want to verify a TrialPay POST, as I’m not going to do that here. Just read their documentation and you’ll figure it out quickly enough.

You will also likely want to add in a bit more error checking and whatnot. I’ve cut things down there to the very basics as described above.

That’s about all there is to it though. I hope that serves as a good starting point for anyone that wants to integrate TrialPay sales into their Infralution IPN.NET system.



P.S. If you want to find out more about TrialPay, click the button:

TrialPay Referral Program

The Licensing Experience with Infralution and DotNetNuke


Posted by Cynic | Posted in .NET, C#, Databases, DotNetNuke, Online Marketing, Software, Solutions to Problems, Super Simple, Web Sites | Posted on 20-09-2011

Tags: ,

I don’t think that I’ve ever done a licensing or purchasing flow exactly the same way twice. Well, a couple times, but mostly I experiment with both major changes and minor tweaks.

This time around for the Super Simple Photo Resizer Social Edition, I’m doing things more or less right. There are a few things that still could be improved, and a few things that I’m not really all that happy with, but like my friend Nick Longo says, “Release at 80%.”

However, overall, I think the current functional set that I’ve got mapped out for Photo Resizer Social Edition are pretty good, and will deliver a solid user experience. My goals on the user-experience side are:

  1. Make it easy to purchase
  2. Make it easy to get and enter the license
  3. Make it easy to get a lost license back

Each of those has a real upside for users, and an upside for me as well (respectively):

  1. I make more money
  2. Fewer support emails
  3. Fewer support emails

But I also have some other goals.

  1. Cut down on piracy
  2. Cut down on piracy
  3. Cut down on piracy

For a little guy like me, piracy hurts. Badly. It also hurts users, because it removes the financial incentive to continue development. You’d be surprised at just how many people like to get paid for their work, and how much they enjoy having food on the table and paying their bills. ­čśë

I recently got an email from someone who purchased some other software that I write. This is part of that email:

I could have pirated the software if I wished as it is easy to crack which is something you need to work on, but I thought the software is so good that I would pay you the money for a genuine copy and support its future development.

I’m glad he bought a copy! It quite literally puts food on the table.

However, I don’t want to get into piracy here. Instead, I’d like to go over some of the things I’m doing with the new licensing scheme…

The flow looks something like this (click to zoom):

Super Simple Photo Resizer Social Edition Licensing Flow
Now, I’m leaving out a lot there because it would just be boring details, but that’s the basic flow.

The user gets 2 emails:

  1. PayPal receipt
  2. License email with account information

Now, in the past I’ve done licensing manually, which has been in many ways pretty easy, but it’s not been without its pain as well.

I’ve previously mentioned that I’m using the Infralution toolchain for licensing, but nothing is perfect “out of the box”, so I’ve done a good amount of customization. Having been burnt very badly in the past, I tend to purchase source code licenses whenever I can afford to. This leaves me the freedom to get down into things and tweak, fix, or just pimp-out stuff. Infralution offers source code along with their various products, which is another reason why I strongly recommend them to people whenever the topic of software licensing or payment integration arises.

I’ve also raved about how much I love DotNetNuke. It’s a fantastic CMS/portal written in ASP.NET (VB.NET in the past and now in C#), and comes with a BSDish license. However, I’ve been hesitant in the past to do much integration due to time constraints and other factors. However, this time around, I’m aiming to get things done more or less “right”.

Neither the Infralution ILS nor their IPN.NET integrate into DotNetNuke, so all of that is goodness that I need to take care of. Luckily, DotNetNuke is very well designed and integration isn’t really much of a problem. It’s really only a matter of getting it done and testing things out to make sure that they work. The trick is to try and make certain that I don’t step outside of the framework, and don’t create potential future issues for when I upgrade the DNN version. (Moving from DNN v2.1.2 to v3.x was a NIGHTMARE.)

ILS and IPN.NET take care of all the license generation and authentication, so the only thing needed is to get that into DNN. The relevant user-portion of the database is (click to zoom):

DotNetNuke Users Roles Database DiagramTo get ILS and IPN.NET working there, I needed to create 2 new entries in the database:

  • A Role for licensees
  • A ProfileProperty to store licenses

No new tables needed to be added, and no table modifications were needed. So, everything fits into DNN nice and cleanly.

A Note About the Database: When installing DNN, I would highly recommend using object qualifiers. These are prefixes for the database objects (tables, stored procedures, views), and will help to guarantee that well written modules that use them do not have conflicts. IPN.NET and ILS do not support object qualifiers, and have table names that could be used by other modules. As such, I’m very happy that I always stick with the wisdom of using object qualifiers because it’s made things much safer, and has allowed me the freedom to use the DNN database for the IPN.NET and ILS Authentication Server. Later on, this will let me create custom modules or do additional programming that let me access all user data in 1 place. The advantages here are never-ending.

When a user purchases a license through PayPal, PayPal then securely contacts my IPN.NET instance, and I then process the transaction by either updating the user’s existing profile, or creating a new user profile for the user and updating it with their new license information.

Since IPN.NET has no DNN integration, everything needs to work around that, and consequently, needs to be done at a low-level. Luckily,┬áthe DNN community is quite large, and there’s a lot of code out there to help with very low-level stuff like this.

The first step to integration is to create a user, and there’s some existing code out there that helped me get jump started:

Creating a DotNetNuke User via SQL

So starting from there, I’ve got a new account for the user and it has their license securely stored.

Next, there’s a password problem there… I certainly don’t want to use a known password, so that needs to change. Again, thanks to the DNN community, I’ve got the solution:

Updating a DotNetNuke User Password via SQL

However, what password do I create? What I wanted to do initially was to create a pass phrase instead of a password. However, being the grammar-Nazi that I am, and being constitutionally incapable of generating icky passphrases, I realized after some investigation that any decent passphrase generator would take me far longer than I was prepared to spend. So… Thank you again to the .NET community, I have a ready-made password generator that creates strong passwords of an arbitrary length:

Strong Passwords in C#

So that problem is also solved, in more detail that I’d care to bother with too! It creates passwords that look like these:

  • a+7P9A*rp6F&
  • So5={9WsM+g7
  • Ax8$+3JwD=a2
  • Ky8-i?H6Dw3&9%sS$rX54Q!f{2eLPp_7

The nice things about that password generator are that it

  • Leaves out ambiguous characters, e.g. I vs. | vs. l vs. 1 or 0 vs. o vs. O
  • Lets you choose the length of the password
  • Mixes in upper and lower case letters, numbers, and symbols

As far as being able to remember them? Bah! Not going to happen. Which is why I wanted to have a pass phrase generator, but, you do what you can with the time you have.

Now, code-wise, there are a few points where things need to get done:

  1. MS SQL Server stored procedures
  2. The IPN.NET project
    1. Default.aspx.cs
    2. Add in the RandomPassword.cs class
    3. Add in the “DnnLicenseIssuer.cs” class
    4. Modify the “Keys.htm” file

The MS SQL Server stored procedures won’t have any impact on DNN if done right. The prerequisite PropertyDefinitions and Roles need to be there, but that’s simple enough.

The RandomPassword.cs and DnnLicenseIssuer.cs classes won’t have any impact on the IPN.NET installation, so there’s a lot of freedom there.

However, changes to the Default.aspx.cs file will break across IPN.NET upgrades unless care is taken to migrate those changes to any new IPN.NET version. Luckily, everything that needs to be done can be done in this method:

private void ProcessPurchaseItem(PurchaseItem item, int quantity)

However, if you’ve actually sold a license, and the payment is successful, there’s only 1 spot that you need to modify, which will look something like this:

DnnLicenseIssuer dnnLi = new DnnLicenseIssuer(ipn, item, keys, false);
if (dnnLi.HasExistingAccount)
// Do stuff for license email
// Do stuff for license email

So you can easily minimize the impact there and make future upgrades very easily.

The “Do stuff” part contains customizations that I’ve written for the license email. If users have an existing account, then they get a different email than users that I’ve created an account for.

Of course it is possible to go further, and create users irrespective of whether the license payment succeeded or failed, and follow up later, however, it’s not one of my requirements at the moment.

The End Game

There’s a plan behind all this though. I’m not going to spill the beans quite yet, and it won’t get done for some time yet. However, all of this has a forward-looking purpose, and when I finally make it to that stage, I’ll post back on what I’m doing and the results.

Until then, check back at Super Simple over the next few weeks as the new Photo Resizer Social Edition is coming out very soon.



Creating Urgency for Sales with Infralution Licensing System


Posted by Cynic | Posted in .NET, Business, C#, Databases, Money, Online Marketing, Software, Solutions to Problems, Super Simple | Posted on 15-09-2011

Tags: ,

I need to create a large number of “products” for Photo Resizer, but they’re really all just the same product with different prices. And not 2 or 3 prices, but more like 20 or 30 prices. Actually, I’ll likely end up creating more than 30, but that’s a detail.

It may seem strange to some people as to why I would do this. I’ve had people tell me to just set one price and be done with it. Well, that’s all fine and dandy, but it also shows a lack of understanding about how to sell software. Just because you’re a rock star coder, doesn’t mean you’re a rock star marketer.

So, what I’m going to cover now are some motivations and reasons for the problem, and how I’m solving it. There are of course other ways to create problems, and other ways to solve them too. ­čÖé

  • Urgency and creating urgency
  • The Infralution Licensing System and License Tracker
  • The Code: Creating massive numbers of products for the License Tracker database

Urgency and Creating Urgency

When you’re selling, you sometimes need to create a sense of urgency for people to BUY NOW! Not later. Not tomorrow. NOW! Stores do with with 1-day sales, or “on sale until <date>”. The same sort of thing can be done for software. You just tell people that there’s a deal to be had RIGHT NOW, and that if they don’t buy your product RIGHT NOW, then they’re going to miss out.

What happens when you do this is that you effectively remove a barrier to purchase for the customer. They have 1 less reason to “not buy”, and 1 more reason to buy. The more things you can do like this, the better. Typical things include telling potential customers how your product will benefit them and make their lives better, or offer free shipping, or… You get the point.

The way in which I am creating urgency is with an initial steep discount for the product that decreases; that is, the price increases over the course of the trial period. e.g. Today it’s $5 and tomorrow it’s $6, and the day after that… So… BUY NOW and SAVE~! I’ve done it before, and it works.

The Infralution Licensing System and License Tracker

There are lots of ways to license your software, but the one I like is from Infralution. The Infralution Licensing System, or ILS, integrates with their IPN.NET product as well, so it gives me a way to license the software and collect money for it; those are 2 very different things and should not be confused.

ILS includes a program to help keep track of licenses and customers called License Tracker, which up until now I’ve never used. Since I’m looking to automate as much as possible at this stage, I’m moving things over to it now.

License Tracker stores data in a database; I’m using MS SQL Server for that. To add a new product, you simply open up a new form and enter all the data then click OK. Sounds simple enough? Well… Not when you want to add in a truck load of products; it is extremely tedious and painful. I don’t want to copy and paste 500 million times, and I don’t want to change my mind later on and end up copying and pasting another 500 million times.

Since License Tracker is a database-connected application, all data in it is just the data in MS SQL Server. This makes it easy to deal with your data because you can simply connect to the database and do whatever you feel like. As such, I wrote a utility to generate SQL for products, or rather, for product variants, though it could also be used to create top level primary products as well.

My simple “SQL Generator for the Infralution Licensing System License Tracker ” (that’s a mouthful) lets you enter data for a product and generate product variants very quickly. It even lets you increase product costs by a set increment, and lets you auto-increment IPN item numbers. Here’s a screenshot of it (click to zoom):

SQL Generator for the Infralution Licensing System License TrackerIt’s pretty basic, but it saves product information and settings automatically so that you don’t need to enter everything the next time.

You simply fill in the form and click the “Generate SQL” button. The SQL is then appended to the Generated SQL text box at the bottom of the form. You can automate part of it with the Automatic Increments settings, or quickly change the price manually and click the Generate SQL button again. It’s MUCH faster than copying and pasting for every field.

Now, you do need to know what you are doing, and the “Parent Product ID” needs to be the primary key for the product’s parent in SQL Server, so this isn’t a utility for just anyone to use. However, if you use the Infralution Licensing System and License Tracker, you’ll already be familiar with everything in there, and you won’t have any problems in using it.

Once you have your SQL, you can simply review it to see that it’s what you want and run it in MS SQL Server Management Studio, or whatever you use to execute SQL against MS SQL Server.

After you run your SQL, simply open up License Tracker and all your products will be there.

The Code: Creating Massive Numbers of Products for the License Tracker Database

To make things easier, I’m including the full source code for download here. Please note that I’ve chosen for it to be licensed under the WTFPL 2.0, so you have maximum freedom to “Do What The F*** You Want To”. If you don’t like that license, then feel free to send me lots of money and I’ll give you another license. ­čśë

Download Source Code for SQL Generator for the Infralution Licensing System License Tracker

The download includes all source code and a debug build that you can run immediately.

The code is commented extensively, so you can consider that the “documentation”. If you have any questions, which I rather doubt anyone will, you can post a reply here. (Also email me to let me know to respond. You can email me through the contact page at

I hope that helps someone out.