Atomic Energy

In dealing with e-commerce solutions over the last several weeks intensely (and the last several years in general), I have come to the conclusion that there are four different categories of e-commerce solution providers: gateways, processors, providers and promisers. 

In understanding these categories, as in all projects where you have a defined goal, it is important to understand what your e-commerce goal is. Most e-commerce occurs where the vendor wants to sell something to the customer. All is good and fine, until the vendor needs to take payment. That payment can occur in lots of ways (barter, cash, gold, diamonds), but online usually takes some form of electronic payment. This is usually a credit card payment or e-payment (like PayPal), but can also be e-checks, especially since the creation of Check21 and the wider acceptance of ACH in recent years.

So you, as a vendor, have a need, once you have decided to accept payment from a customer, to accept that payment from them. You have three choices:

1. Gateways: Gateways provide nothing more than a direct line to handle the nitty-gritty of credit card processing. Authorize.net is one of the more well-known, but others exist. When you use a gateway, you are saying, “I want to do everything myself, I even have the credit card merchant account, but someone has to process the payment.” Your costs are likely to be quite low, your technical requirements quite high. Unfortunately, most of the gateways are actually still quite primitive. For example, it is nearly impossible to get decent machine-readable (= automated) information about chargebacks, and when they do arrive, they often lack enough information to match them to an initial transaction that may have occurred months or longer ago. To make matters worse, they often include the original credit card number, which is unnecessary and complicated PCI-DSS compliance.
2. Processors: The processors provide you with some basic services on top of the gateways. First, they may use multiple gateways, providing some reliability and redundancy for you. Second, they may do a lot of the heavy lifting to automate some processes so that you can use Internet-age technology and tools to manage payment processing. Third, they may include direct access to some of the e-payment systems, which a gateway cannot. Fourth, the processor brand may provide some level of security and comfort for your customers. Fifth, they can alleviate the PCI-DSS compliance burden in some cases, by removing the need to handle credit card data at all. Sixth, they can provide some more rapid response, for example notifying your infrastructure of payment events (authorize, capture, reject, etc.). Notable entrants in this area are PayPal, Amazon and Google. 
3. Promisers: The promisers promise the world. They are all in one solutions that include a cart, coupons and discounts, cross-sells, up-sells, customer reporting, you name it. They may even have a complete licensing system. They handle everything for you. They are the easiest to implement and get started with. Some examples include Kagi, esellerate and others. Many have been bought up by Digital River, which, unfortunately, has let the engineering and investment side (and certainly the user experience side) slip into well below mediocrity. The downside of any of these? You are tied in tightly. If what you want doesn’t work with them, tough luck. You may have to change your business model (as one company I recently worked with did) to suit their infrastructure rather than change your systems to meet your business model. They also make it difficult to work part-and-part, e.g. licensing from one supplier, sales from another, cart from another. Finally, their costs tend to be fairly high.
4. Providers: The providers category is pretty new. They live somewhere between the Processors and Promoters. A great example is FastSpring. You manage the user experience on your site. However, when you are ready to actually sell or add to a cart, you do it on their site. They provide open URL access to the product, and many of the instant notification features of Processors, along with the price and promotion management features of the Promisers. Their costs tend to be somewhere between the Processors and Promisers. They are very quick to get up and running, especially the new Web 2.0 ones, but sometimes lack the catalog/product controls that you would get from managing it on your own (although then you would have to implement it).

Where do these rank for those looking for a commerce solution?

• If you have simple products to sell, with fairly straightforward up-sell, cross-sell and discount needs that you do not expect to grow or change – a.k.a this is either a hobby or a small business that will remain small – the Promisers will suffice. Be prepared, however, for high variable costs and great pain if you ever want to pull apart… you will likely need expert help to tease apart the components. On the upside, consultants like us love those. 
• If you are doing very complex transactions, recurring transactions, and need to store your own payment data, or if you have very high volumes, you are most likely to use the gateways. Your fixed cost in maintaining them will be high, but you will have the greatest control and direct access and lowest per-transaction costs.
• If you are prepared to maintain your own storefront, or desire to do so for control purposes, but want a decent system to handle reporting and ease of access, use the Providers. I have been very impressed by FastSpring thus far, although some level of control over what products are available under what conditions would be hugely useful. Just about everyone who sells any volume has specials that only apply to certain customers under certain conditions (time, past purchases, membership in a special club, etc.). The Providers make everything available if you know the URL, and in the age of the Internet, nothing remains hidden for long. Security by obscurity is a recipe for insecurity.
• If you just have a few products to sell, and you want the lowest-cost fastest implementation, go for the Processors. PayPal as the lead, followed by Google and Amazon, have made implementing payment processing extremely easy, although the easiest to use are also easy for anyone to fool, or even set up a pirate page on a Russian server that even non-technical users can use to fool your page. As soon as you add some security and controls, it gets more complex. Kudos to PayPal for their usage of encrypted buttons to allow you to still use their “easy” product (Website Payments Standard) but provide some protection.

So having gone through the above (see previous posts), there are basically two choices when it comes to implementing licensing schemes.

1. Sell the upgrade. Many sales systems, even fairly primitive ones, support this. You create a separate SKU for each major release, and possibly for each minor, and a separate license key scheme for each major release (but not minor). The licensing ensures that different minor releases within the major release will allow cross-upgrades (or downgrades). For the sales, you create a coupon that says, “if a return purchaser bought one of the following SKUs (all those in the previous major release), give them x% off for this SKU (all those in the latest major release). Note that some systems do have limitations with this. For example, esellerate can apply the coupon for everyone, one time, or one time by email. But what if a previous purchaser bought 3 copies? Well, then, you are out of luck.
2. Sell the plan. You need to manage your customer data set on your own. You then need to manage the customer interaction with the sales system, so that only appropriate users see the appropriate pages, either the regular SKU with an appropriate applied discount, or special discount SKUs. 

Inevitably, one will ask, can any sales system handle being so controlled from your Web store, such that it will only display appropriate pages to appropriate people? One does not want to have a new buyer get to the supposedly hidden pages and get the product for free! As the old saying goes, “security by obscurity is insecurity.” Here is a short summary of what I have found.

1. No open-source cart system manages this. Period. Zen-Cart, osCommerce, CubeCart, even the new Magento all fall short. Nor I have seen a commercial system that manages it.
2. The sales channel providers, like FastSpring, which combine sales management, reporting, up-sells/cross-sells and the like, but have the actual catalog per se on your page, are focused on letting you sell anything you want, provided the URL is correct. Needless to say, this is not something they offer. FastSpring is pretty impressive, but is not built for this. 
3. Surprisingly, the best solutions come from the least-featured providers. PayPal Website Payments Pro, Google Checkout XML API and Amazon FPS all are strong in this area because they allow your site to talk to their service, server-to-server, and will reject any transaction that your server has not approved. The downside to all of these is that accepting credit-card information means you must become PCI-DSS compliant, a not-insignificant effort. It is not very difficult, especially if you never store credit-card information, and almost all of the recommendations are good security practice, but a small ISV may simply not have the time to deal with it. I recently worked with a client on converting to PCI-DSS compliance. We did the analysis very quickly, but the conversion is taking time. 
4. The lower-end services of these Internet giants are less functional in this area, with one shining exception. Google Payments HTML API and Amazon Buy Now buttons both depend on data stored in the user’s browser to submit payment information. A user could easily change the information and get the cheaper or free prices, and even set up a Website to make it easier for others. The shining exception is PayPal, which is strong because of its weakness. Like the others, PayPal’s Payments Standard system is built around buttons that are configured and submitted from the user’s browser page. Because users can modify these and submit, thus cheating the ecommerce seller, there is an option to encrypt the buttons, thus allowing PayPal to authenticate that the values are valid. Put in other terms, PayPal’s need to resolve its weakness provides a strength in dealing with this issue. 

A number of providers also provide post-processing notification. FastSpring has Notification by POST to a Web site, PayPal has IPN. These can provide backstops, but they are not recommended for this purpose. Why? Because they only allow you to confirm or deny a sale after it is done, meaning the user thinks s/he is done and then gets told, sorry, no deal. This may even run afoul of consumer protection laws.

Conclusions:

1. For the short-run, if you need to boost sales by selling upgrades, sell upgrades to major versions, free updates to minor versions, and use whatever your sales channel will support.
2. For the long-run, get control of your customer data within your own databases, and provide authenticated Web API access. Wrap the data with a business logic layer, and then provide interfaces to your sales channel, so you can control how customer specials are managed.
3. If you need more complex structures, use PayPal or similar services until the mid-channels are mature enough to provide them.
4. Hopefully, at some point, the mid-channels like FastSpring will expand to provide these services.

In the previous post we discussed implementing Option A: Sell the Upgrade. Now we will address Sell the Plan. 

Sell the Plan has a lot of appeal for ISVs, especially when you start to sell to businesses, non-profits, or any group that budgets. The benefits are:

1. Predictable cash flow. The reality is that most individuals and organizations that have recurring charges simply keep on paying them. This creates more predictable cash flow for your ISV business.
2. Earlier revenue recognition: Let us assume that you release version 1.0 in Jan 2006 and 2.0 in Apr 2007. If you sell the upgrade, the purchaser of 1.0 will wait all the way until April to pay you. On the other hand, if you sell the plan, by Jan 2007 he is already paying you the plan fees for the coming year.
3. Easier recurring sales. Most organizations budget capital expenditures, especially for new purchases, separately from ongoing operating expenses. The $50 they will spend next year to buy the next version of your product must be approved and budgeted, and for the following version, and again. On the other hand, if buying the product the first time comes with an annual $50 charge for “maintenance,” it gets built right into the ongoing operating budget and is automatically approved.

It is important in this scenario to give new purchasers at full retail a “free” year (more or less, depending on your customers, but a years is fairly standard) of upgrade plan. The free helps you sell, but also avoids the sense from them that they are getting no support in terms of patches, upgrades, etc. 

So how do we go about implementing “Sell the Plan?” Again, we have multiple scenarios.

1. New purchaser: This purchaser simply buys the product outright at full retail price, in our case $100.
2. Return purchaser on plan: This person should be able to upgrade for free, whether it is because they are within their “free” year, or because they are within another year (or ten) of paid plan.
3. Return purchaser off plan: This person should be able to upgrade, but not for free. Instead of buying the new product, they buy another year (or more) of plan. This plan is normally sold at some discount off the current retail price of the product. In our scenario, we will assume it to be 50%.

How does implementation of each of these scenarios happen?

1. New purchaser: This is a standard sale. The purchaser buys it outright, gets a license key, installs, and goes.
2. On-plan purchaser: This is complex. This can be implemented either via the licensing system or the commerce system.
   • Licensing system: The licensing system needs to issue licenses that understand when upgrades are allowed and when they are not. It further needs to recognize when a version was released, compare that to the range of dates for which upgrades are allowed, and then allow or disallow the upgrade. I have not seen a single, solitary license system that can do this.
   • Commerce system via product SKUs: As in the “Sell the Upgrade” scenario, you can either have limited availability SKUs or the same SKU as new purchases, but with special coupons. In either case, the commerce system needs to  recognize that this is a returning user and precisely what rights they have. I have seen no commerce systems that do this correctly, either. The closest I have seen is that some systems will issue coupons based on previous purchases of a particular SKU by a returning user. However, these systems all treat the upgrade (for free) purchases as if they are new, and thus give them a whole new year for free.
   • Commerce system via plan SKUs: This is an approach that no commerce system has recommended, yet offers an intriguing new way. Each product has its own SKU, and each plan for free upgrades (12 month, 24 month, etc.) has its own SKU. When someone purchases a product outright, they receive the free upgrade SKU bundled with it. When they come to upgrade, the commerce system should recognize that they have a recent purchase (within time frame) of the plan SKU, and either give them access to the limited availability free upgrade SKU or the appropriate discount coupon for the regular SKU. Again, I have seen no commerce system do this outright, but some have shown flexibility in the right direction.
3. Off-plan purchaser: An off-plan purchaser is one who once was on-plan, and is now off. Essentially, they need the ability to subscribe to the plan again. This requires a separate SKU for plan, followed by a recognition of the ability to join the “free download” group. However, it is important that the commerce system only allow someone who once purchased to join the plan, else anyone will just buy the plan SKU at less than full retail and get free upgrades.

Conclusions:

1. Commerce system intelligence is a must. No system has shown the ability to do this, but some have shown promise. See my follow-up post on commerce systems.
2. Some of this can be handled in licensing, but some must be handled in commerce systems. As before, make commerce systems your focus.

As a follow-on to the previous post about licensing strategies for ISVs, I would like to discuss the nitty-gritty implementation details. It turns out that the open market has not been very kind to mISV firms, and have left with very few options, none of which provides the desired flexibilities. This post will discuss “Sell the Upgrade.” A follow-on will discuss “Sell the Plan.”

So you want to implement sell-the-upgrade. To do that, you need to have several scenarios, all working in concert. You have released one products with three versions: 1.0, 1.5 and 2.0. You are currently selling 1.5, but will soon start selling 2.0.

1. New purchaser: This is, of course, easy. You have a single product, call it SKU15, representing version 1.5. Everyone pays full price, say $100.
2. Return purchaser: This is someone who already bought 1.0 and now wants to upgrade to 1.5. The return purchaser should pay nothing for version 1.5, as it is a minor upgrade. You have a few choices: 

• Keep the same SKU for upgrade purchases and new purchases of all releases of the major version of the product. SKU10 covers version 1.0 and 1.5, whether new purchase or upgrade. Rely on your licensing system to recognize the allowed upgrade. This usually works if the same license set covers both version 1.0 and 1.5.
• Use the same SKU for upgrade purchases as for new purchases, but different between minor versions, and rely on your commerce system to recognize that this purchaser bought 1.0 already and is thus allowed a 100% discount off the purchase price of that SKU. 
• Use a different SKU for upgrade purchases than new purchases, say SKU15U (U for upgrade), and rely on your commerce system to recognize the allowed purchase. In other words, it is a limited availability SKU. 

In both of the commerce-system-dependent solutions, an upgrade means buying the new product, but having the commerce system recognize the purchaser as someone who purchased before, and thus give them the product at 100% off, either via discount of limited availability SKU. It is important that the commerce system recognize that the purchaser is a returning purchaser, and exactly how many copies they have the right to upgrade. For example, someone who bought 5 copies of 1.0 should have the right to purchase 5 copies of 1.5 for free, but not 50 copies. There are varying ways to do this, but very few, if any, commerce or cart systems seem to know how to manage this.

Now we move to major upgrades. People are buying version 2.0.

1. New purchaser: This is, again, easy. You have a single product, call it SKU20, representing version 2.0. Everyone pays full price, say $100.
2. Return purchaser: This is someone who already bought 1.0 or perhaps 1.5 and now wants to upgrade to 2.0. If you don’t give upgrade discounts, it is very easy: they are just like a new purchaser. However, most ISVs, especially mISVs, give upgrade discounts. For argument’s sake, let’s say our discount is 50%. The return purchaser should pay $50 for this upgrade. Managing this through the licensing system is nearly impossible, since they can only upgrade if they pay something, which means a new purchase, which means a new license key. Additionally, you are likely to have a separate SKU for this new version. Thus, your only choice is to manage it through the commerce system. Within the system, you have a few choices: 

• Use a different SKU for upgrade purchases than new purchases (SKU20 and SKU20U). Rely on your commerce system to recognize the allowed upgrade. Again, this is a limited availability SKU.
• Use the same SKU for upgrade purchases as new purchases (SKU20). Rely on your commerce system to recognize that this is an upgrade purchase, and thus provide the appropriate 50% discount.

In both of these cases, you depend on your commerce system for a lot of intelligence about returning purchasers. Once again, I have seen few, if any, commerce systems that can do this properly.

So, what is the solution to sell-the-upgrade?

1. Recognize that most of this is going to happen through the commerce system. Have a good cart of system that ties closely into your customer history database.
2. Make licensing as easy as possible, and have it trust your commerce system. Licensing may solve some of it, but major upgrades between SKUs will have to generate new license keys, so focus your energies on commerce systems.

esellerate, despite many other severe issues (not least of which is absurd pricing), does have the ability to do this decently using coupons. Their customer technical support is also excellent.

I have recently spent time with the various open-source cart solutions: magento, zen-cart, oscommerce and cubecart, as well as esellerate and a nice newcomer service, FastSpring. I will write a separate blog post on these services and carts soon. Unfortunately, none of these has the ability to do this cleanly. 

Next up: “Sell the Plan.”

For the last several months, I have been involved with a particular very small ISV, almost a micro-ISV (mISV), as it prepares for growth. One of the key elements we identified is that its pricing model – unlimited free upgrades – is not exactly conducive to good revenues and profitability. Although it seems obvious, it needs to be stated, and for several reasons.

1. Founders sometimes feel that to charge for upgrades would somehow offend existing customers. This was not at all the case with this customer. Nonetheless, many are afraid to do so. The opposite is true. Most customers not only understand that the service a vendor provides is ongoing, and requires compensation, but want to ensure the vendor will be around for a long time. Wisely, this founder had been saying from the beginning that as of now, upgrades are free, but he reserves the right to change it.
2. People equate value with price. Sure, everyone looks for a bargain, but if something seems too cheap, too good to be true, they subconsciously, and sometimes consciously, assume it to be, well, cheap and worthless. For a great reference, see Joel Spolsky’s article in the Inc magazine of July 2008.
3. Repeat customers are always lower cost to sell to than new customers, in every business.

It seems fairly simple, then, to charge for upgrades. But how to do it? We were left with two primary options:

1. Charge full price for a new customer, 40-50% off for upgrading customers at major revisions. This means buyers of 2.5 get 2.6 for free, but pay discounted price for 3.0. This is known as “sell the upgrade.”
2. Charge full price for a new customers, give them 12 months (or similar) free upgrades, whether minor or major versions. When the 12 months are up, they get no upgrades or updates. At that point, they can buy another 12 months (or similar) of free upgrades at 40-50% off the then-current retail price. This is known as “sell the plan.”

Sell the upgrade is cleaner to manage and implement, and is similar to what most large vendors do. When you buy Windows XP or Mac OS X Tiger, you get all the service packs for XP and updates for 10.4 for Tiger for free. You do, however, have to pay for Vista or Mac OS X Leopard.

Sell the plan has better revenue timing (it comes in earlier), and better cash flow. Further, it makes it much easier to sell to organizations that budget. Rather than a capital expenditure each year or two, it becomes a maintenance expense, built into the operating budget each year automatically.

For the above reasons, we went for sell the plan.

In response to the unending requests I have received for recommended reading, I have posted a permanent page with a list of books that I recommend. Obviously, they vary depending on circumstances, but all of them have jewels of wisdom to impart.

The list is short and just beginning, but is expected to grow as I have time to add books.

You can always access it from the “Pages” section of the blog’s sidebar.

Avi