An edited version of this paper was scheduled to appear with the title "Paying the E-Commerce Way" in the June, 1998 issue of Network VAR.
Internet-based electronic commerce has finally emerged from the sidelines and taken on the patina of a full-blown, mainstream business process. Its success is due to a number of factors, including the intellectual support of organizations like CommerceNet, the logistical support of payment companies like CyberCash, DigiCash, and Clickshare, the financial support of the banking and finance industry as a whole, and perhaps most important of all, the trust of a growing consumer base. Together, these concerted efforts have made it trivial for consumers to safely, accurately, and easily make purchases over the Internet.
There is another side to the equation, however, and that is the merchant's perspective. While it is now a simple exercise to purchase something over the World Wide Web, it has also become relatively simple to sell merchandise over the Web and be paid in a secure and timely fashion. In this article, we will discuss the evolving status of electronic money; the roles of banks and credit card companies; and the process of establishing a commercial Web presence, including hardware and software requirements, network impacts, and security concerns.
"Electronic money" comes in several flavors, but it is important to note up front that Internet-based electronic payment options are not a new form of transactable currency. In actuality, they are electronic payment software packages that simulate traditional cash, check, credit card, or debit card transactions. CyberCash, for example, offers a range of payment solutions, including traditional credit cards, micropayment (25 cents to $10) support, and checking account withdrawals. On the other hand, DigiCash's ecash™ simulates cash transactions by creating digital "coins" with specific values that can be exchanged between a purchaser and a merchant, or between two private individuals. Consumers that use these forms of payment enjoy several key benefits. They can safely and easily conduct purchases on the web; and, they can pay with either cash or credit card. Merchants benefit as well: their accounts are credited for a sale as soon as the transaction takes place; they can do business with virtually any bank or payment processing house; they can run a 24-hour, unattended operation; and, they can draw from a marketplace that is truly global in scope.
In the real world, companies create a relationship with a financial institution to do business. They open bank accounts for checking and savings, and may establish a line of credit to draw upon. In many cases, they may establish a merchant account with the bank or with one of its agent companies so that they can accept MasterCard and VISA, or may contact Discover, American Express, or any of a number of other credit card providers directly to secure permission to accept their card. If the company's financial records and account history are in order, and the company is deemed to pose an acceptable risk, the financial institution will grant the credit relationship and determine a reasonable service charge.
At the same time, the bank will create a separate new relationship between the company and the bank's credit card processing agency. The processing agency is a trusted third party that receives credit card purchase data from the seller, verifies the purchase with the bank, then allows or rejects the purchase. In some cases, the bank or financial institution will provide a point-of-sale terminal that will read the magnetic stripe information on the back of a card, dial a telephone number, connect to a remote host, verify the status of the credit card, determine whether the purchase is to be allowed, and report back to the merchant. Many POS terminals collect the transactions during the business day, then upload them to the host computer for processing at the end of the online day. This process is known as terminal-based or POS capture. In other systems, the host collects and processes each transaction as it is received, or simply stores the transactions for processing later. This is referred to as host-based capture.
For a Web-based business, the process is similar. Companies must first register with a merchant bank and be authorized to accept credit cards as payment for purchases. Next, they must request that the bank set up their account to accept credit cards via whatever software package or packages they have chosen to be their Internet payment scheme(s). The major credit card processing entities have now certified most of the generally accepted electronic payment software packages such as CyberCash and DigiCash for payment; these entities include Wells-CES, VisaNet/Vital, Global Payment Systems, Checkfree, and a number of others.
Because online Internet transactions are currently classified under the so-called "card-not-present" form of transaction (transactions that are conducted in such a way that there is no face-to-face contact between the purchaser and the seller), most credit card agencies treat them as mail order/telephone order (MO/TO) purchases. They may require some form of secondary identification such as a drivers license number, address verification, or social security number. The major Internet payment schemes comply with these requirements.
The goals of Internet commerce are twofold: to emulate the real economic world in such a way that consumers can shop, select, and pay for merchandise in the cybermall as easily as they do in the real mall; and, to give merchants a way to accurately represent themselves online, to accept payment for merchandise, and to do so with integrity and trust. The payment software packages that have emerged in the last few years are designed to facilitate this process by replacing the physical purchasing and payment processes with online equivalents. The software can usually be downloaded from the site of the issuing company or ordered by mail; either way the process is straight-forward.
The payment software is only part of the story. We must also consider the network itself.
There are many different products available today for creating a Web-based payment capability, not to mention a plethora of Electronic Data Interchange (EDI) and Point-of-Sale (POS) products. The selection of secure commerce products will depend upon what you are trying to accomplish as a merchant, the volume of business you expect, the amount of your expected transactions, the breadth of payment services you wish to offer, etc. -- essentially the same kinds of things that would help dictate decisions in a traditional payment environment. Additional issues in cyberspace that may affect a product decision include the size of your organization, level of technical sophistication, range of products, type of interface to your cyberstore, and where your Web site is actually hosted.
There are a number of third-party payment systems that can be employed with a commerce server, some of which were mentioned earlier. These include Clickshare, CMU's NetBill, CyberCash's CyberCash and CyberCoin, DigiCash's Ecash, Digital's Millicent, First Virtual Internet Payment System (FVIPS), and ICVERIFY. While these schemes differ from each other in detail, they have a number of similarities in concept; specifically, a merchant builds a secure server that interacts with a third-party's financial agent that is also employed by the customer. In some cases, the financial agent is a bank that deals with electronic money; in others, it is a financial institution that issues checks. If your site accepts credit cards, the server must be able to interact with credit card verification sites.
Before selecting a commerce product, you must first select a hardware and software platform. While Unix has been the traditional Internet server platform-of-choice for many years, use of other platforms -- notably Windows NT -- is growing at a rapid rate. For any number of reasons, Unix is not always the best choice of platform for secure Web servers, although it is ideally suited for use by an Internet service provider (ISP) offering a Web hosting capability (because of its excellent multitasking capability) or where a large number of server hits is expected.
Unfortunately, Unix requires an amount of local administrative skill that is often lacking at the casual user site, particularly if Unix is not already in place. Unix is much more complex than Windows NT but is no longer significantly more powerful. This has resulted in large growth in Windows NT-based Internet servers over the last couple of years. And what about Macs? A Mac-based server makes sense in some environments, such as in an existing Mac shop, or one where there is already a great deal of Mac expertise and no compelling reason to bring in a new operating system.
While cost and available expertise will be important in driving the server decision, security cannot be overlooked. The relative security of these operating systems is often a matter of near-religious debate among their proponents and detractors. In fact, one would be hard pressed to objectively declare one of these systems particularly more or less secure than the others. In any event, security is not a one-time operation: it requires constant vigilance and monitoring. One could argue, then, that a well-understood and maintained operating system is safer to use than a "more secure" but less understood system.
| Product Name | Unix | Windows NT | ||
|---|---|---|---|---|
| IBM Net.Commerce | X | X | http://www.internet.ibm.com/ commercepoint/net.commerce/ | |
| IBM/Lotus Domino Go Webserver | X | X | http://www.ics.raleigh.ibm.com/ dominogowebserver/ | |
| Ironside Technologies Ironworks | X | http://www.ironside.com | ||
| Lotus Domino.Merchant | X | X | http://www.net.lotus.com | |
| Microsoft Commerce Server | X | http://www.microsoft.com | ||
| Netscape Enterprise Server | X | X | http://www.netscape.com | |
| Open Market Secure Server | X | http://www.openmarket.com | ||
| O'Reilly WebSite Professional | X | http://website.ora.com | ||
| StarNine WebSTAR/SSL | X | http://www.starnine.com | ||
| Stronghold: Apache-SSL | X | http://stronghold.c2.net |
NOTE: "Unix" above is generic; none of these products work on all versions of Unix, but on
some combination of AIX, BSDI, FreeBSD, HP-UX, IRIX, Linux, Solaris, SunOS, and/or others.
Table 1 lists just a few of the currently available products that provide a secure Web commerce environment. Each of these products includes a Web server, meaning that they can be used in lieu of other Web server software such as Microsoft's Internet Information Server (IIS) or the National Center for Supercomputer Application's (NCSA) httpd. In addition, these products provide a Web page development environment, conceptually similar to Microsoft's FrontPage or NetObjects' Fusion. Support for Web programming languages and various application program interfaces (API) allow the site developer to create the Web pages and the necessary interfaces into supply and customer databases, and to handle financial transactions. These products also employ secure communications protocols, create public cryptography keys, and communicate with appropriate certification authorities (CAs). Remember that the product you consider must not only provide a Web interface for customers, but must also be able to handle financial transactions and, possibly, interact with other servers at your site.
So, assuming that you will host and maintain a secure commerce server, how do you go about selecting a product? There are a number of features to look for, including:
There are two main protocols used to provide secure communications over the Web, namely the Secure Hypertext Transfer Protocol (S-HTTP) and Secure Sockets Layer (SSL). Figure 1 shows how these two protocol stacks compare to each other and to HTTP.
--------
------------- | HTTP |
-------- | HTTP with | |------|
| HTTP | | extensions| | SSL |
|------| |-----------| |------|
| TCP | | TCP | | TCP |
|------| |-----------| |------|
| IP | | IP | | IP |
-------- ------------- --------
Port: 80 80 443
Protocol: http shttp https
FIGURE 1. Protocol stack, port number, URL protocol tag, and
|
HTTP, of course, is the communications protocol used between a Web client (i.e., the browser) and a Web server. HTTP runs on top of the Transmission Control Protocol (TCP) and the server uses well-known port 80. HTTP employs URLs of the form http://host/filename.html.
S-HTTP was developed by Enterprise Integration Technologies (EIT) for the CommerceNet Consortium and is commercially available from Terisa Systems (a joint venture of EIT and RSA Data Security). It is a set of software extensions to HTTP that support secret key cryptography, key exchange, message privacy, and message signatures. S-HTTP is designed specifically to be used with HTTP and, like HTTP, operates over TCP and uses port 80 on the server. S-HTTP employs URLs of the form shttp://host/filename.html.
SSL was developed by Netscape Communications to provide message privacy, message integrity, and client/server authentication. SSL is fundamentally different from S-HTTP in that it is an extension to the client and server TCP/IP protocol stack; whereas S-HTTP is designed to provide security for HTTP, SSL is designed to provide security to any TCP application, including as HTTP, FTP, Telnet, and Network News Transfer Protocol (NNTP). SSL operates over TCP and the server listens on port 443; it employs URLs of the form https://host/filename.html. An important side issue here is that is SSL is employed at a site, be sure that any firewall-based packet or application filtering will allow SSL access to your secure Web server.
S-HTTP and SSL are widely used today, although they are not the only security schemes available for e-commerce applications. Other protocols, such as MasterCard and Visa's Secure Electronic Transactions (SET) and TradeWave's Virtual Private Internet (TradeVPI), are also available and vying for position.
There are several things that need to be considered when setting up a secure commerce server. In some sense, the least onerous part is the software installation itself; much more complex is the creation and management of certificates, which are essential for public key cryptography systems used in e-commerce. While keys and certificates are not as hard as, say, rocket science, they are topic areas that must be fully understood before making irrevocable decisions such as whether to be your own CA or which external CA to use. You will also have to establish relationships with third-party financial institutions for handling electronic payments, credit card authorizations, and funds transfer. These are, in fact, areas where consulting with a knowledgeable third-party makes a lot of sense.
When planning for a secure commerce site, you must also take the network infrastructure into account, using many of the same criteria used to select the server hardware and software. Obviously, you will need a full-time Internet connection if you are going to allow around-the-clock buying by visitors to your Web site. The speed of the connection should be based on the volume of business you experience; a 56 kbps or ISDN connection may suffice for a few purchases a day but as the number of transactions increases, so must your connection speed. Remember that not all network traffic will be generated by the purchaser: your server will also be communicating with other servers on the Internet to verify transactions. A slow link, then, makes the entire transaction take longer if performed in real-time, and Internet consumers today have little patience. In a non-real-time environment, speed of the link matters less, although you still want visitors to be able to get to your site and cruise around it at optimal speed.
Many sites employ one or more non-secure servers (i.e., servers not running SSL or S-HTTP) to allow customers to browse and select items, and then switch to a secure server for actual financial transactions. Of course, these systems work best when sharing databases, a subject beyond the scope of this article.
As we discussed earlier, you will also have to decide what kinds of payments you are going to take, such as cyber-based cash or checks, ordinary credit cards, or accounts established with your company. For online cash or checks, you will have to establish a relationship with an appropriate third-party financial institution. For credit cards, you will have to connect to an agency to verify credit cards. If you set up your own accounts, you will have to define a payment mechanism.
Finally, although well beyond the scope of this article, some sort of firewall protection should be used in conjunction with your secure server. If you are directly connected to the Internet, a firewall can be used to control the protocols and applications allowed in and out of your site, log incoming and outgoing traffic, and provide additional protection above and beyond what is available with your secure server.
As you progress in your investigation of building a Web server, you will find that there are costs to consider. These will vary with the size and activity at your site, but general cost elements (assuming that you host the commerce server at your own site) include:
As a final note, there may be some good reasons to have your ISP host your Web server. Even at a cost of $300-2000 per month, the hosting might pay for itself because the ISP will provide the high-speed connection to the server and handle security, as well. The resultant savings may well offset the hosting charges.
The process of setting up a commercial enterprise on the Internet is a straight-forward process, and requires most of the same steps that are required to set up a physical business. A relationship with a financial institution must be forged; accounts must be opened; certification to accept credit cards as payment for online purchases must be acquired; and payment software must be installed. Furthermore, a server platform must be selected, based on a pre-existing hardware environment, and desired features; security considerations must be taken into account; bandwidth requirements must be carefully assessed and accommodated; personnel must be selected and adequately trained; and advertising and other miscellaneous activities must be accomplished. Once these items have been completed, the commerce site will become a trusted "store" on the Web, and will begin to generate online revenue for your company.
Steven Shepard (aravaca@sover.net) is a Senior Member of Technical Staff and Gary Kessler (kumquat@sover.net), at the time of this article's publication, was the V.P., Information Technology at Hill Associates, a telecommunications training and education firm with headquarters in Colchester, VT. Both have written books and many articles for industry publications.