Linux and E-Commerce
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.
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.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- Be a Mechanic...with Android and Linux!
- New Products
- Users, Permissions and Multitenant Sites
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- High-Availability Storage with HA-LVM
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Solving ODEs on Linux
- Non-Linux FOSS: MenuMeters