Linux and E-Commerce

The experience of one company selling Windows software using Linux to build a reliable e-commerce solution.

by Yermo Lamers

Through the use of Linux, open tools, and a few commercial components, my company built a reliable e-commerce solution that through its flexibility has enabled us to make our business more effective and explore opportunities that would otherwise have been unreachable.

The capabilities required to implement such a system used to be solely in the domain of larger organizations that could afford large cash outlays and dedicated personnel. Linux has changed this by making a top-quality, open platform available at virtually no cost.

Background

In the beginning, we were selling our Windows shareware stock-tracking software, Personal Stock Monitor, through a third party. It soon became clear this service didn't offer the flexibility we needed. When looking at other options, we realized no third party would be able to do what we wanted. For starters, we wanted to be able to do the following:

Make the purchase process as easy and quick as possible.
Get to know our customers better and take the opportunity to get more feedback from them.
Experiment with various business ideas, change our pricing, provide upgrade incentives, provide discounts, etc.
Track sales through multiple distribution channels and get a much better understanding of how and why people were buying our software and, more importantly, why people weren't.

Clearly, we needed a better solution that could be changed quickly as the need arose without a great deal of effort or expense. Being a small company, we were constrained by limited resources. However, we were convinced that doing e-commerce ourselves was a business necessity.

The Business Case for Linux

After looking at a number of options, we chose to build our own solution and base it on Linux for reasons both technical and business-related, including:

We could use inexpensive hardware and share it between a number of tasks. This meant we didn't need to buy an extra box and didn't need to upgrade the one we had.
We could administer the server remotely as easily as from the local keyboard. For a small company like ours, this was one of the many reasons we didn't even entertain using Windows NT.
Linux is rock-solid reliable. As eight months of operational experience would show, Linux never seems to crash. It just runs, and as a result, we have more time to focus on business.
All development tools and applications we needed are available for Linux and most of them are either Open Source or carry the GPL. All are of high quality.
The ``openness'' of Linux provides a significant business benefit. We can always get the answers we need when we need them at no cost. We've never been slowed down due to lack of information when using Linux.
All critical applications we needed were available for Linux.

We could have chosen other options that would have worked equally well, but they would have cost significantly more money and required much more expensive hardware. For our particular needs, we couldn't find anything we believed could do the job better at any price.

The Pieces and Parts of an E-Commerce Solution

Once we decided on Linux, the rest of the system fell into place.

Transaction Service

The first thing we needed was a way to authorize transactions. We looked at a number of e-commerce tool providers with varying levels of sophistication. It turns out these e-commerce companies provide the equivalent of the credit card machine you see at convenience stores. This means all order tracking, accounting features, reconciling, demographic reporting, feedback gathering and interactions with the customer along with most of the administrative features you need are left for you to provide.

For technical reasons, we ended up choosing the Cybercash service. This provides a library of C routines and Perl modules supported under Linux. Cybercash calls this software development kit (SDK) their Merchant Connection Kit. It's essentially a credit card transaction SDK and makes no assumptions about the rest of your business. It provides the kind of flexibility we need.

The Cybercash account didn't cost any money upfront, but it did have a transaction fee. More information is available on their web site at http://www.cybercash.com/.

We especially liked the fact that it wasn't tied to a web interface. It's just an SDK with which you can build your own e-commerce desktop applications, CGI scripts or server modules. It's a very flexible toolkit and was exactly what we were looking for.

Merchant Account

The second component we needed was a Merchant Account that supported the transaction service we chose. In order to process credit card transactions, you need to have a merchant account that acts as an intermediary between your bank account and your customer's credit card company. Getting a merchant account involves a large amount of paperwork, a credit check and a setup fee.

Other than finding a merchant account that supported Cybercash, we didn't see much difference in the offerings aside from cost. There's typically a setup fee and fixed transaction fees. Then the credit card companies take their cut. However, when all transaction fees are totaled, you're still usually under 4%. Compared to the fees typically charged by third-party e-commerce companies, the difference can add up to non-trivial sums. In our case, we earned back the money we spent setting up our Linux based e-commerce solution in a couple of months based on this percentage difference. Typically, on-line software stores for shareware will charge between 15% and 40%.

SSL Server

The next component we needed was an SSL (secure sockets layer) server that encrypts traffic to and from the web server. It increases your customer's confidence and improves the security of on-line transactions. We were comfortable with the Apache web server, so we wanted to find an SSL server based on Apache. We looked at a couple of vendors and ended up making our decision based on price. We chose the Raven SSL web server, and it has worked well for us. Their tech support has been very helpful. Today, a number of other options are available.

Certificate Authority

In order to set up an SSL server, you need a ``certificate'' from a third party known as a Certificate Authority. The SSL vendor will give you a temporary invalid key to use for testing purposes.

The certificate is designed to verify the identity of you and your company. It provides assurance to the customer that they are actually dealing with your company. Unfortunately, getting a certificate can be paperwork-intensive, as you must verify your identity to the Certificate Authority. This usually means giving them your incorporation paperwork. In our case, it took slightly over two weeks to go through the certificate process. The Certificate Authority then issues you a certificate key via mail. It's just an encrypted block of text that you cut and paste into your SSL server setup.

We ended up choosing Thawte for our certificates because they were less expensive. The only problem we've had has been with older browsers that no longer recognize the certificate authority. This generates some spurious errors. However, since fewer people are using the 3.x versions of Netscape and MS Internet Explorer each day, we don't see this as a major problem.

Database

We wanted to be able to do more with our e-commerce solution than just process fixed transactions. We wanted to have a system that could easily be extended as the need arose. Additionally, we wanted to keep track of all kinds of variables so we could answer a number of questions, such as:

Is the purchase process easy enough?
Where do customers hear about us?
What versions sell better?
Is our pricing effective?
Are there any trends in our sales that might shed some light on our customers?

As a result, we needed a robust and flexible database back end to store and organize all of this data. We needed to balance the speed and scalability of the database back end with reliability and ease of programming. Additionally, we needed easy access to the data and the ability to alter the structure on the fly. Beyond that, we didn't want to spend much money.

We decided on MySQL (http://www.mysql.com/). It's extremely fast, multi-threaded, flexible and supports a large subset of the SQL standard. It's a very popular database for web applications, and a good Perl interface is available for it. In addition, the licensing is flexible, and in many cases you are allowed to use it at no cost. An active mailing list and a tremendous amount of information is available on their web site.

Unlike the SSL server or the merchant account, our choice of database ended up being a critical one, as it was one of the components that made a difference when it came time to go after new business ideas.

Perl

We talked about implementing a ``commercial grade'' e-commerce solution in C or C++. This implied a major development effort and a lot of work if we decided to modify it later.

Being afraid to lock ourselves into a solution we couldn't change easily, we opted to develop in Perl, which saved us a great deal of time at the expense of some runtime speed. We figured since we were running under Linux that the overhead added by using Perl would be negligible, and by the time it became an issue we would be making so much money we could buy a faster machine.

Another key advantage of developing in Perl is that the code is quickly and easily changed. On-line business changes so fast it's hard to keep up. Anything we could do to make it easier on ourselves was in our business interest.

Putting It All Together

Once we had all the pieces identified, it was fairly easy to put it all together. Just two pieces of code were left to write. The first managed the experience customers have when they come to our web site to place an order. The second was an administration interface that enabled us to do some maintenance tasks. The first version of our solution worked as follows:

Display a form on the secure server that allows the user to enter their credit card information. It's linked to a CGI script that does the bulk of the work.
In the Perl CGI script, verify the FORM fields and make sure all required fields are filled with values that make sense. If there is an error, let the user know, log the error in the database and send an e-mail notice to the administrator. We wanted to know how well users were doing with our order form. As a result of this tracking, we ended up improving the order process significantly.
If no errors are found in the form, format a Cybercash transaction package with all the relevant fields and pass it to the Cybercash Perl module for submission to the Cybercash servers.
Take a look at the response codes from Cybercash. Quite a few fields are returned, but the key ones are the transaction status and the AVS (address verification service) code.
If the transaction was not authorized, log an error in the database, let the customer know and fire off an e-mail message to the administrator.
If the transaction was authorized, check the code, which is a simple test designed to reduce fraudulent transactions. It compares the numerals in the address and zip code provided by the customer to the address and zip code present in the records at the credit card company. The reasoning is that if someone steals your credit card, it is unlikely they have your address as well. AVS codes include ``Y'' for everything matched correctly, ``A'' for only the address matched, ``Z'' for only the zip matched and ``N'' for nothing matched. Unfortunately, the AVS system is available for US addresses only.
Send the customer a thank-you message by e-mail, log the transaction in the database for later perusal and send the administrator e-mail indicating that a transaction was authorized.

The administration interface allows us to enter orders by hand for phone orders, mail-in orders and fax-in orders. It also allows us to edit individual records and review all transactions and errors. We use this interface on a daily basis to manually examine each transaction for signs of fraud. (A complete discussion of fraud detection is outside the scope of this article.) We've been seeing a fraud rate of around 1-2%, which we are told is about industry average.

The way our system is set up, transactions get ``authorized'' but do not automatically get ``settled'' until we've had a chance to review them. It is possible to automate the entire process so that no human is involved, but we prefer to look over all transactions prior to letting them go through.

Operational Experience/Lessons Learned

Having our own e-commerce solution built on a reliable platform with flexible tools has meant we can change our system to experiment with various methods for improving our business.

First, we noticed through all of the error tracking we built into the system that quite a few customers would come to the order form, try to enter their information once, make some simple error such as not filling in a zip code and not return. We made some changes to our data entry form and reduced the number of fields down to the bare minimum. This seems to have improved things dramatically--there was a noticeable increase in sales.

One afternoon, we decided to add a ``comments'' box to the order form to obtain more feedback from our customers. Strangely enough, we've found that customers are much more likely to provide us with detailed feedback while they're ordering our product than they are at any other time. Because we chose MySQL and Perl to build the system, adding this option was literally 30 minutes of work and gave us a whole new opportunity to know our customers. It has proved surprisingly valuable.

Another lesson we've learned through experimentation is that making our product easy to buy makes an incredible difference in the quantity we sell. You can have a great product, but if it's not easy to license, few will buy it. Again, the flexibility of the tools we chose allowed us to try a number of different approaches until we found one that worked for us.

On October 20, 1998, we came out with the 3.0 version of our stock-tracking application. Based on quite a few different parameters, not the least of which were comments from customers, we decided to change our pricing and bring out two editions of the product: a standard and a gold. We also realized we could offer ``upgrade'' incentives on-line. We ended up taking our single product e-commerce solution and modifying it quickly to sell essentially four products: two editions and two upgrades, each at a different price point.

Another interesting side effect of running our own e-commerce solution and being able to modify it quickly for new situations was ``affiliate transactions''. We were presented with a few opportunities to have other companies promote our software from their web sites and on their CDs. Obviously, the question arose of how to account for the sales. Again, the flexibility of the tools we had chosen allowed to us to respond to these new opportunities. Had we not chosen Linux and this set of tools, we would not have been in a position to go after this new business.

Conclusion

Choosing to build a Linux-based e-commerce solution has provided a critical benefit for our business and allowed us to effectively respond to constant change.

Yermo Lamers (yml@dtlink.com/) is co-founder of DTLink Software (http://www.dtlink.com/), a company that develops and distributes Personal Stock Monitor for MS Windows, an Internet-based stock tracking application. He has built and licensed quite a few revenue-generating server systems on top of Linux since the days of SLS .99pl14 and looks forward to the day when Wine can be used to run Personal Stock Monitor on Linux.