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:
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.
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.
Once we decided on Linux, the rest of the system fell into place.
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.
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%.
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.
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.
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.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide