Linux and E-Commerce

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.

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:

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.

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 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.

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:

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.