Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp.com.

Notice: This material is excerpted from Running A Perfect Web Site with Apache, ISBN: 0-7897-0745-4. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.

Chapter 18 - Financial Transactions

Many of the Web sites in development today are a result of the dreams and hard work of the entrepreneurs of the Internet, infopreneurs. If you're interested in conducting commerce via your Web site, this chapter is a must read.

This chapter covers one of the most important and quickly developing areas of Internet technology: adding secure financial transactions to your Web site. There are a number of different approaches and the chapter reviews the current high profile systems: eCash, First Virtual, CyberCash, Secure Pay and Web900. It would be an understatement to say that security plays an important role when discussing finances and personal information. You take a look at how you can provide your customers the security they desire when transacting business with you. Some Web servers have built-in security and this chapter covers them briefly. Finally, this chapter offers you some alternative methods of transacting commerce.

In this chapter, you learn about:

  • A brief history of online commerce

  • Network security measures

  • Electronic Cash/Credit equivalents

  • How to become an electronic merchant

  • Software commerce systems for your Web site

When reviewing and discussing secure financial transactions, you need a basic familiarity with the concepts of Internet security implementations; so that is this chapter's first topic.

Development of Financial Transactions on the Internet

Internet Financial transactions began with the market for commercial online services such as Prodigy, CompuServe and America Online. Early on, the concept of an "Electronic Mall" was introduced first by Prodigy and later implemented by the other commercial online services. In fact, Prodigy was envisioned initially to be little more than a convenient place to shop! The Prodigy Electronic Mall was the result of a joint effort involving CBS, Sears, and IBM. It allowed Prodigy customers to order a wide variety of products, ranging from groceries and flowers to automobiles and other high ticket items. Transactions were done by credit card and the purchases were delivered to the buyer. In this transaction, Prodigy acted as a broker between the vendor and buyer. Each vendor's orders were send to them by Prodigy at regular intervals. Prodigy received a percentage of the sales and garnered additional profits by selling advertising space.

An entirely new business concept was created! The Prodigy system is a considerable success and is a credible model for infopreneurs around the globe. However, there is a key difference between Prodigy and your Web site on the Internet. Prodigy is a closed service that its users connect directly to via modem. This means that the security of the connection is guaranteed.

The strength of the Internet (and its weakness where commerce is concerned) is that it is an open system. This means that your connection can be "listened to" by snooping ears. But because the lure of online commerce is so powerful, many large companies are working hard to implement a secure system for their own version of the Electronic Mall. The main forces driving the development of Secure Internet Protocols are the companies striving to reduce costs and increase profits by selling their products and services through the Internet. You will probably begin to hear many people talk of the "frictionless economy" where Internet technology removes all barriers to commerce regardless of time or space.

Another force is the promise to banks and merchants of cheaper, Electronic Data Interchange (EDI), the system currently used for credit card validation and commerce between large companies. EDI has been in use for years and generally requires dedicated communication lines and equipment. The Internet strategy is inherently simpler and less expensive to use. When banks accept and begin using an Internet version of EDI, their operating costs, and the costs to merchants for credit card validation will drop.

Currencies

The Internet is an international phenomenon; it's not nationally specific to the United States. Someone anywhere in the world can reach anywhere else in the world easily and seamlessly. Not so in the "real world" where there are borders, nationalities, languages, and currencies. When selling products or services on the Internet, you may have to contend with different currencies and exchange rates. Most Web sites specify in US currency (US$45) the prices of their merchandise; this is a good strategy. The buyer then must deal with the trouble of differing currencies. Many e-cash systems will eliminate this burden as well by converting currencies when funds are transferred into a special e-cash account.

Online Purchasing

The Internet, in general, and the World Wide Web, in particular, offer a convenient outlet for selling products and services. As the Web matures, more and more merchants are including some way for visitors to purchase from them. A number of strategies are in use, from some version of an electronic money, secure transmission of credit card numbers, taking orders and shipping them COD, to requiring visitors to establish an "account" with the merchant prior to purchasing a product or service. Only using electronic money or secure transmission of credit card numbers require any new implementation of technology; this chapter focuses on those strategies.

The introduction of electronic, virtual money has raised some serious concerns for everyone involved. The nature of this electronic money is digital, ones and zeros, and instantly simple to reproduce and defraud. The companies involved in creating digital money have created elaborate systems to prevent fraud.

The transmission of secure financial information raises more concerns. How do you prevent the information from being picked up by the wrong person and unencrypted? Technically, most of the systems currently in place are as secure as the current credit card validation system used in almost every store in the western world. The robustness of the security system is not enough, the customer needs to feel that it is secure. It becomes a marketing issue.

Security Concerns

The Internet is an inherently insecure system. Data is available to anyone with the will to retrieve it. Every week, you hear or read about someone breaking into, hacking, a "secure" computer system, like the Department of Defense. It is worthwhile to remain cautious when dealing with secure information and computers. Commonly accepted "secure" systems will eventually be exposed with weaknesses, and will then be enforced or retired in favor of the next "secure" system. The best security is not a powerful encryption, it is diligence. If you keep careful track of your transactions, maintain adequate security within your company, follow common secure practices, (like using passwords), you will be less likely to be the victim of some kind of fraud.

As a transactor of electronic commerce, you must be concerned with two areas of computer security:

  • You must provide a way for your users to exchange information with you in a secure manner.

  • The data you receive from your customers must be protected from falling into the wrong hands.

    Your data can become vulnerable through sociological hacking, Brute Force hacking, Keyboard readers, and the ever popular "Packet sniffing."

    Sociological Hacking

    If you know a lot about somebody, it is often fairly easy to figure out passwords. A favorite pet, a child's name, or activity are all commonly used as passwords. You may have given passwords and private keys to coworkers and friends or you may leave that kind of information near the computer. Many instances of people breaking in to "secure" systems wasn't through some marvel of computer hacking, it was the result of being observant and nosy. All administrative personnel at your site must have proper account names and passwords.

    Brute Force

    It's possible to decipher any encrypted message given enough time. Computers are wonderful tools for deciphering. They can scan through every possible combination of an encryption until they find the code that unlocks the message. This process is referred to as a Brute Force. For many years, a 40-bit RSA encryption was considered invulnerable. With the increased power of computers and the advancements in mathematical algorithms, it was broken. Computers will keep getting more powerful and mathematicians will keep coming up with new ways of code breaking.

    Keyboard Readers

    While not common, it is possible to "read" the keystrokes entered into a keyboard using a simple program that attaches to the keyboard driver. This program reads unencoded keystrokes and saves them into a file for later reference thus defeating any encryption placed on the inputted information.

    Packet Sniffing

    Packet sniffing is the process of attaching a piece of hardware or software to an existing network and watching the packets flow through. Data transmitted across the Internet is broken into packets. Each of these packets is vulnerable to sniffing. Packet sniffing is not illegal; it is used to diagnose network problems. Misuse of the information is illegal but it is extremely difficult to detect a packet sniffer.

    Public Network Security

    There are two general kinds of networks, private and public. The Internet is a public network and this chapter covers only security systems for a public network. Network security spans three concerns: privacy, message authentication, and signatures.

  • Privacy in transmission over public networks is accomplished by encrypting the sensitive data with one of three private key algorithms: RC4, IDEA, DES.

  • Message authentication proves the data was not tampered with. The message is encoded with a one-way hash (an irreversible encoding) and the hash is encrypted with the sender's private key. The result is a message digest. The message digest can be opened with the sender's public key and compared to the hash of the received message. Current message digests include MD4, MD5 and SHS.

  • A signature is proof of origin of the message. A signature is a bunch of information about the sender encrypted with a private key. The matching public key can be used to unlock the signature. Associated with signatures are certificates. Certificates are messages signed by a trusted central authority's private key that validate the sender and the public key of the sender for the current message. Certificates can be opened with the central authority's well-known public key.

    An online reference for Internet security is the World Wide Web Consortium. Visit their security area at http://www.w3.org/pub/WWW/Security/.

    Session Negotiation Protocols

    Session Negotiation protocols allow two parties engaged in a secure transaction to negotiate and establish the encryption algorithm and protocol that will be used for the session. For example Client A has SSL and SHTTP available and Client B has SHTTP and PCT available. Within the negotiation, they will establish SHTTP as the session protocol. All this negotiation exists within the client/server software; users do not need to worry about how to negotiate for session protocols. Three session negotiation protocols are used: SSL version 3.0 supported by Netscape and Microsoft; S-HTTP supported by Spry & NCSA; and PCT supported by Microsoft. These three protocols all function basically in the same way: they provide for negotiating what security protocols and algorithms will be used for the session. They all depend on a public key algorithm, of which there are three to choose: RSA, Diffie-Hellman, and DSS.

    • SSL version 3.0 (Secure Socket Layer) Netscape Communications Corporation has introduced and implemented SSL into their ubiquitous browser and Commerce Server. SSL provides privacy and a secure connection between the client and server. For online information about SSL, visit http://proto.netscape.com/newsref/ref/netscape-security.html.

    • S-HTTP (Secure HyperText Transport Protocol) Verifone Inc. based in Menlo Park, CA has created and proposed the S-HTTP standard. S-HTTP uses the RSA public key cryptography and features end-to-end secure transactions. S-HTTP is an extension to the existing standard HTTP. For online information about S-HTTP, visit http://www.ncsa.uiuc.edu/InformationServers/WebSecurity/index.html.

    • PCT (Private Communication Technology) Microsoft developed PCT as an enhancement and replacement of Netscape's SSL. It is designed for general purpose business and personal communications. PCT supports privacy, authentication and mutual identification. For more information about PCT, visit http://pct.microsoft.com/.

    Encryption Algorithms

    Encryption has been around for a long time. It involves taking a piece of data and making it unreadable. Encryption algorithms actually garble the data. They are used instead of public key encryption because they are much faster. Once the data is encrypted, it will appear as digital garbage to anyone that doesn't have the proper "key" to unlock or decode the data. Over a public network, encryption allows the transmission of secure information. The security of the data is only as good as the encryption algorithm. Three robust encryption algorithms are available for use: DES, RC4, and IDEA. For online information about encryption and cryptography, visit http://axion.physics.ubc.ca/crypt.html.

    • DES (Digital Encryption Standard) Developed in the 1950's by IBM, this is the standard used in ATM "PIN" numbers. DES uses only 56 bits in the encryption so is more susceptible to a brute force attack than RSA. DES is the standard accepted by the US government.

    • RC4 (Ron's Code 4) Ron Rivest of RSA developed RC4. It is marketed by RSA Inc. RSA claims that RC4 is 10 times faster than DES and it uses a variable key size in the algorithm.

    • IDEA (International Data Encryption Algorithm) Xuejia Lai and James L Massey of ETH Zuria created IDEA. It uses a 128-bit key algorithm.

    Public Key Algorithms

    The implementation of Public Key Algorithms resolves the problem of encryption key management. When a piece of data is encrypted, a key is created to unencrypt the information. As long as you have the key, you can read the file. If you have multiple encrypted files it would be possible to have a number of "keys" that you would have to keep associated with the appropriate data. One way around this is to create two keys. One key is used to encrypt the data and the other is used to decrypt it. The key that encrypted the data can not decrypt it. One key is called your private key, the other your public key. If someone wants to send you an encrypted message, they need to use your public key to encrypt it. Your public key is by nature, public, available to anyone who wants it. Any data encrypted with your public key can only be decrypted by your private key. This way you only ever need one key.

    Digital signatures ensure that the data is from the sender that the data says it is from and that the data has not been changed or modified en route. To create a digital signature, you encrypt information about yourself with your private key. Anyone with your public key can decrypt and thus check your signature. A one-way hash is created by sending the sensitive message through a function that results in some 'number', and then encrypting that number with your private key. Anyone with your public key can decrypt and thus check the enclosed hash against the hash of message received. The following may be used in the creation of public signature algorithms; RSA, Diffie-Hellman, DSS.

    • RSA (Rivet-Shamir-Adleman) This algorithm was developed by three mathematicians: Rivet, Shamir, and Adleman. RSA is the most commonly used public encryption algorithm. RSA is online at http://www.rsa.com/.

    • Diffie-Hellman This is the first public key based encryption algorithm. Proposed by Whitfield Diffe and Martin Hellman. Diffe-Hellman is the basis of a number of implementations such as Pretty Good Privacy (PGP).

    • DSS (Digital Signature Standard) National Institute of Standards and Technology created this standard. DSS employs Digital Signature Algorithm (DSA) as the algorithm. DSA is much slower than RSA and it uses between 512 to 1024 bits for the encryption key.

    eCash

    eCash uses the concept of an electronic "coin." The coin retains its value before, during, and after a transaction. Each coin is actually a registered serial number with an associated value. The bank that created the coin maintains a database of their serial numbers to ensure no duplicates are created. Part of the serial number points to the specific minting bank. To make a purchase, the buyer sends sufficient electronic coins to the vendor. The vendor either deposits them into a bank account, or stores them for later use. Currently, the only bank to support eCash by exchanging it for "real money" is Mark Twain Bank. eCash requires that proprietary software be installed on both the customers and merchants computers. eCash uses a simple graphic interface that stays resident on the clients computer and acts as a kind of virtual Automatic Teller Machine (ATM ). When the client asks to buy something, the merchant's eCash software will send a request to the client to confirm the purchase (see fig. 18.1).

    Fig. 18.1 - Example of the eCash interface.

    When the client agrees to the payment by clinking on Yes, the payment amount, in this case, $0.02 is transferred from the client to the server. The display for the client will decrease to $34.98 and the server's balance will increase by the same amount.

    This is a very simple, clean strategy for providing online shopping. However, there are some disadvantages:

    • The client must be running Windows 95 or Windows NT.

    • The sellers choice of Web server is limited to roughly one dozen servers.

    • eCash only supports two national currencies, US dollars and Finnish Markars.

    Mark Twain Bank

    Currently, Mark Twain bank is the only bank that will convert eCash in to real money. Mark Twain Bank is in partnership with DigiCash providing eCash for financial transactions. Mark Twain bank is located in St. Louis, Missouri. They are listed with the FDIC and they offer online services beyond eCash.

    Mark Twain Bank maintains a Web space with information about eCash. We recommend their online tutorial located at http://www.marktwain.com/ecash_in.html.

    Who Uses eCash

    A number of companies are currently using eCash to enable online shopping from their Web site. The following is a partial list of these merchants.

    • AUTO-NET is an online forum to buy and sell used vehicles.

    • Royal Copenhagen sells fine Jewelry from Denmark.

    • Products from Zale sells steel framed homes, water filtration systems, books, food and jewelry.

    • BioNet offers herbs, homeopathies, vitamins, natural cosmetics and other healthful products.

    Setting Up Shop-Server on Windows

    Enabling someone to purchase from your Web site using eCash requires the server component of eCash called "shop-server." eCash has set up a server with the shop-server software, so a merchant can have their Web site hosted on the eCash server.

    eCash works with the shop-server in the same way Netscape works with a Web server. eCash can only interact with a Web site that has the shop-server software installed and running.

    If you have set up and are managing your own Web server. If you're leasing Web hosting from an Internet Service Provider, you may have problems setting up shop-server. Shop-server requires a CGI bin be set up and available. eCash has a set of CGI files created that once installed allows a customer with the installed client software to purchase products from you. The shop-server works very simply: when the client requests a hyperlink that you have designated as one that costs money, the shop-server sends a request to the client for payment. When the client accepts the request, the transaction takes place and the client receives or will receive the product. DigiCash has posted complete instructions for installing and setting up the shop-server on a number of different servers. Currently there are a limited number of servers that are known to be able to run shop-server.

    DigiCash has a well-designed and informative Web site that describes eCash and offers all the component pieces needed to add eCash to your Web site (see fig. 18.2). Go to http://www.digicash.com/.

    Fig. 18.2 - DigiCash home page.

    These are the Web servers that can implement eCash:

    • EMWAC HTTPS server

    • WebSite

    • WebHub

    • Netscape Communications Server

    • Netscape Commerce Server

    • Netscape FastTrack Server

    • Microsoft Internet Information Server

    • Process Software Corporation Purveyor

    • Internet Factory Commerce Builder

    • Apache

    • NCSA

    Microsoft Merchant Server is a Web server that will soon be able to implement eCash.

    First Virtual

    First Virtual is a small company that acts as a transaction broker. No custom software is required, unlike with eCash and CyberCash. All transactions are done through e-mail and then through regularly accepted channels. Neither the buyer nor the seller need to worry about data encryption, key management, or other security concerns. First Virtual bills the merchant a fee for every processed transaction, similar to credit card companies.

    How First Virtual Works

    First Virtual acts as a transaction broker, when someone completes the process of buying a product from you, First Virtual will bill the buyer's credit card for the purchase. Generally these billings are every ten days and are a part of the regular credit card billing. If a buyer makes a series of small purchases that total less than US$10, First Virtual will wait ten days before posting them. After the buyer has paid their credit card bill and First Virtual has received the money from the credit card company (Visa or Mastercard), the money is held by First Virtual for 91 days before it is deposited into the seller's account. This holding period is designed to protect First Virtual from buyers who might contest the purchases and from the credit card company who might bill First Virtual for reimbursement.

    The First Virtual based transactions are fairly straightforward, but time consuming. The buyer requests an item for purchase by entering a VirtualPIN; the seller tells First Virtual, who then sends an e-mail to the buyer to confirm the transaction. Once confirmed by the buyer, the transaction is processed by First Virtual.

    All buyers must have a VirtualPIN to make purchases with the First Virtual system. The VirtualPIN is a buyer identifier. It does not contain any sensitive information such as credit card numbers. With First Virtual, no financial information is sent across the Internet.

    To become a seller using First Virtual, you will need each of the following:

    • A private e-mail account

    • A Visa or Mastercard

    • A checking account that accepts direct deposits through the United States Ach system

    • A VirtualPIN, (supplied by First Virtual)

    To use InfoHaus:

    • All buyers must have a VirtualPIN.

    To make a purchase using First Virtual:

    1. The buyer selects the product or item to purchase

    2. The server asks for and optionally confirms the validity of the buyers VirtualPIN

    3. The server notifies First Virtual of the transaction

    4. An e-mail is sent by First Virtual to the buyer to confirm the transaction

    5. The buyer then does one of three things: replies "Yes" to confirm the purchase; replies "No" to decline to the purchase; or replies "Fraud" if they did not make the original purchase request.

    6. When the buy replies with a Yes, their credit card is debited the amount of the purchase and the funds are direct deposited in to the sellers bank account.

    Encryption System

    First Virtual doesn't require any new or Internet-based encryption systems. First Virtual uses already established transactions systems for the transactions. Money changes hands through credit card billing, and direct deposits between the credit card companies, First Virtual and the seller. The only information needed is the VirtualPIN, which carries no financial information.

    Who Uses First Virtual

    There are a lot of companies using First Virtual. The following is a partial list of these merchants.

    • Reuters New Media Download detailed investor reports on a wide variety of publicly traded companies.

    • The Autoseller Buy/sell cars, trucks, motorcycles, RVs boats, and parts. The ad's stay online until the vehicle sells.

    • The Washington Weekly The US national politics electronic news magazine.

    • Internet Society The Internet Society is the nongovernmental International Organization for global cooperation and coordination for the Internet and its internetworking technologies and applications.

    Setting Up a First Virtual Account

    To set up a account as a seller, you will need to get a VirtualPIN. To make it easy for a seller to get one, First Virtual maintains an online application form, at http://www.fvcom/newacct/index.html. Fill out this form and First Virtual will send you an e-mail with a 12-digit application number and instructions on mailing your bank information to First Virtual. You will receive an e-mail with your new sellers VirtualPIN when your account is set up. This application costs US$10. This process will work anywhere in the world, but all payments between you and First Virtual will be in US dollars. Once you have received your VirtualPIN, you can sign up with the InfoHaus, an online shopping mall (see fig. 18.3 and the next section). First Virtual offers a FV-API for adding this system to a Web server. An API is an "application programming interface" that allows a programmer to build applications using the technology built in to the specific API. In this case the FV-API is First Virtual's technology bundled to allow creation of more applications using First Virtual. But the FV-API is currently only available to UNIX servers. They do include source code, so it is possible to port over Windows NT, though there is no reference that this has been done by anyone.


    There are two types of VirtualPIN numbers, one for buyers and one for sellers. The buyer's VirtualPIN costs US$2, the seller's VirtualPIN costs US$10. To be a seller you must have a seller's VirtualPIN.

    For more information about becoming a seller with First Virtual, visit http://www.firstvirtual.com/info/sellerindex.html.

    Fig. 18.3 - The First Virtual logo indicates a Web site that accepts payments using First Virtual.

    Welcome to the InfoHaus

    The InfoHaus is First Virtual's shopping mall using their transaction system. You can sell anything legal through the InfoHaus: information, goods, and services. The InfoHaus supports both FTP and World Wide Web (HTTP) protocols.

    Becoming an InfoHaus Merchant

    Once you have your seller's VirtualPIN, you'll need to establish a commercial presence for yourself within the InfoHaus. You will need to send the InfoHaus a series of information including your business name, your VirtualPIN, the private e-mail account that is associated with your VirtualPIN, your preferred currency (currently your only choice is US dollars), your preferred language (currently English is your only choice), and a brief description of your business. This information can be sent to the InfoHaus either as a highly structured e-mail, (see their documentation located at: http://www.fv.com/pubdocs/infohaus-guide-5.txt) or it can be telnetted to them.

    The InfoHaus maintains a structured directory of all the merchants who are set up with InfoHaus. Your listing can be a complete Web space with all the various htmL tricks or it can be a simple text listing of your services. The process for setting up a Web space with the InfoHaus is fairly involved and somewhat difficult given the choices of e-mailing or telnetting the information. It would be advisable to get a decent Telnet program for Windows NT if you want to set up and maintain a Web-based commercial presence within the InfoHaus. The InfoHaus bills for hosting your Web pages at a rate of $1.50 per megabyte of information per month. Additionally there is a $0.29 per transaction fee plus 2 percent of the transaction amount. There is a huge amount of information about the InfoHaus in the form of FAQs (Frequently Asked Questions). While it is not very structured, all the information is available for viewing. Navigating through FAQs is not a simple process. For more information about becoming an InfoHaus merchant, visit their Web site at: http://www.infohaus.com/infohaus.html.

    Resources Available within the InfoHaus

    There are already a large number of businesses who have signed up within the InfoHaus and that number is growing. While lacking a real search engine, the InfoHaus has divided up the listings into four different listings. A potential buyer can search by Topic, Business Name, Keyword, or Date. In addition to the FAQs mentioned above, the InfoHaus has created a Seller's guide, the InfoHaus Helpmeister, and a Newsletter. All of these are available from the InfoHaus home page: http://www.infohaus.com/.

    Who Uses InfoHaus

    There are hundreds of merchants using the InfoHaus. The following is a sample of some of them.

    • LandWare Inc. Publisher of high quality Mac, Newton and Windows software.

    • PSYchIC FRIENDS OF THE WEB This business offers live 24-Hour Professional Psychic Consultation.

    • 1ST INFOHAUS CONSULTING This business can help get a InfoHaus page started.

    For more information about the InfoHaus, visit http://www.infohaus.com/index.html.

    CyberCash

    CyberCash is short for the CyberCash Wallet, which is the result of a cooperative agreement between CyberCash and VeriSign. The CyberCash Wallet gives a buyer the ability to purchase goods and services over the Web, and using a world-wide license of a 768-bit RSA encryption algorithm, CyberCash provides a secure channel for the transaction. The Wallet is a free software program, like eCash, that when installed on a computer allows CyberCash transactions.

    How CyberCash Works

    CyberCash works with the same basic structure as eCash and First Virtual. Figure 18.4 shows the six steps of this process. The process starts with a buyer requesting some product or service (step 1). The merchant's server sends a confirmation message to the buyer (step 2). When the buyer confirms the purchase, the merchants server sends the transaction to CyberCash (step 3). CyberCash reformats the transaction data and sends it via regular dedicated lines to the merchant's bank (step 4). The Merchant's bank then sends an authorization request to the credit card company for the transaction authorization. When the approval (or denial) is complete, it is sent back to CyberCash with the approval code (step 5). CyberCash then sends the approval code to the Merchant who then forwards it to the buyer (step 6). This entire process takes between 15 and 20 seconds.

    Fig. 18.4 - The CyberCash transaction diagram.

    Requirements

    CyberCash, like eCash and First Virtual, requires both the buyer and seller to set themselves up for using it. The following are the requirements for both buyers and sellers wishing to use CyberCash.

    • Buyers will need the CyberCash Wallet, available for Windows 3.1, 95 and NT, Macintosh and PowerPC

    • Merchants will need a merchant credit card account with their existing bank,

    • A Terminal ID from the merchants bank for accepting Internet transactions

    • CyberCash Wallet

    CyberCash Wallet is compatible with the following Web browsers:

    • FTP & Spyglass Enhanced NCSA Mosaic Version 1.15.111.0

    • FTP & Spyglass Enhanced NCSA Mosaic Version 2.0

    • Internet In A Box - Spry AirMosaic Version 03.0A.01.04

    • InternetWorks Version 1.0.3

    • NCSA Mosaic Version 2.0.0b4

    • Netscape Version 1.1b3 and Version 1.1

    • O'Reilly And Associates Enhanced NCSA Mosaic Release 1

    • QuarterDeck Mosaic Prerelease 4

    Setting Up a CyberCash Account

    Setting yourself up as a merchant using CyberCash is relatively easy; there are explicit instructions online (see fig. 18.5 or go to http://www.cybercash.com/cybercash/how/merch_setup.html). There is an online application form at http://www.cybercash.com/cybercash/how/merchantapplform.html that you will need to fill out. After your application has been processed, CyberCash will contact you and begin setting up your online storefront, either on their or your server.

    If your Web browser is not on the list of supported browsers, you will have to manually configure it to work with the CyberCash Wallet. CyberCash has instructions for doing this manual configuration.

    Fig. 18.5 - You can get detailed information online.

    Who Uses CyberCash

    CyberCash is being used by some fairly large Internet players, the following is a partial list of companies using CyberCash.

    • ElectroWeb A reseller of CD-ROM software, hardware, computer peripherals, consumer electronics, music and video games

    • Novell Novell's BrainShare '96 Web site. Learn about the latest Novell technologies.

    • Oracle Database development software

    • Price Online Price Club online

    For more information about CyberCash, go to http://www.cybercash.com.

    Also, CyberCash has submitted RFC1898, a technical review of CyberCash Credit Card Protocol Version 0.8. This document describes in complete detail the workings of CyberCash. This and other RFCs are available on line at: http://ds.internic.net/ds/dspg1intdoc.html.

    Type the RFC number (RFC1898) into the searchable field, and it will retrieve your requested RFC. An RFC is an Internet term meaning Request For Comments. When a new protocol is introduced to the Internet community, generally, an RFC is submitted.

    Secure Pay

    Secure Pay allows for purchasing products through checks. This system has been created by Redi-Check, based in Salt Lake City, Utah. Both CyberCash and First Virtual require the buyer or client to have a credit card. Secure Pay doesn't have this requirement. The buyer sets up an account with Secure Pay, giving them their checking account information, at Secure Pay's secure Web site and then chooses an account name and password. When the buyer wants to buy something, they enter their unique account name and password, which Secure Pay then validates. The buyer does not need any additional software. With Secure Pay, no financial information is transmitted over the Internet, so no security system is needed, (other than the initial sign up, which is secure).

    Requirements

    Secure Pay requires both the buyer and merchant to have bank accounts that will accept checks paid in US funds. No additional hardware or software is required.

    How Secure Pay Works

    Secure Pay is a fairly simple structure. A buyer purchases a product or service from your Secure Pay enabled site. The buyer will have entered their account name and password to make the purchase. This information along with the transaction re-sent to Redi-Check for verification. When verified, Redi-Check sends back a confirmation and then prints a check drawn against the buyers checking account and sends the check to the merchant via regular mail. The funds are available 24 hours after the purchase was made because Secure Pay cuts checks daily.

    How To Set Up a Secure Pay Account

    The first step to enabling Secure Pay as a merchant is to create a merchant account with Secure Pay (see fig. 18.6). They have set up an online order form at http://www.redi-check.com/merchant/online.html.

    Fig. 18.6 - Fill out this form to set up a Secure Pay account.

    You will need to complete this form. The form allows Redi-Check to withdraw US$250 from your checking account as a one-time application and setup fee. Thereafter, there is a processing fee per transaction of 2 percent. After you have completed the application, Secure Pay will contact you to complete the process. Your account will be set up within two working days of submitting the application. Currently, Secure Pay can only handle US and Canadian funds; this affects the buyer more than the merchant.

    Visit the Secure Pay home page for information and applications at http://www.redi-check.com.

    The following is a sample of the merchants using Redi-Check's services.

    • Access Market Square Internet Shopping Mall

    • Icentral's ShopSite

    • Mentor and Associates

    • Windows95.com

    Web900

    Web900 is a unique approach to online purchasing. Using the existing 900 number phenomenon for billing, the merchant can easily charge for online products. This strategy is designed more for selling "digital information" than durable goods. If you have a piece of software, you could sell it online very easily with this system.

    Requirements

    There are no special requirements for the buyer with Web900. The merchant needs to have a server that can run CGI scripts with either PERL version 4.0 or Visual Basic.

    How Web900 Works

    When a buyer wants to purchase something from you, they are shown a page that requests a redemption code. This code is available by calling a 900 number. When the buyer calls the number, the body of the message could simply be the redemption code. The buyer then enters that code into a CGI form which validates the code against an already existing block of codes the merchant has on their server. The buyer will be billed for the 900 number call on their phone bill in increments of US$10 and US$25. When Web900 receives payment from the phone company, they will forward 80 percent of the total to the merchant, keeping 20 percent as a transaction fee. See figure 18.7.

    Fig. 18.7 - Web900 sample form.

    How To Set Up a Web900 Account

    You will need to fill out the service agreement and fax it to Web900. The form is located at http://www.netleader.com/logicom/webagree.htm. While you're getting the form, follow the links to "Sample CGI Script" and download the CGI scripts for your system. Use the Visual Basic-based CGI script if you are using a WINS directory, use the other PERL-based CGI scripts if you are using a CGI-Bin directory. Web900 has created the form to use for requesting the redemption code. Follow the links to and download a copy of this form. Make sure you keep their information intact on the form because Web900 requires it.

    After they have received your agreement, Web900 will send redemption codes to you as an e-mail attachment. Also they will have created your account. With the codes copied to the appropriate directory, the CGI script will work. If you have problems setting up the CGI script or placing the code file, you can contact Web900, they will walk you through the setup.

    Web900 processes checks on the 15th of every month for 45 days prior. For example, the transactions that occurred in February will be processed on April 15th.

    You can find Web900 online at http://www.netleader.com/logicom/web900.htm.

    Secure Web Servers

    Many infopreneurs simply accept credit cards over the Internet by utilizing a secure Web server. No e-cash, virtual checks, or cyber-dollars are needed. Your customers will likely demand that you protect their financial details by implementing a secure Web server. Most credible Web server software companies have either delivered a secure server or are about to.

    This chapter discusses a few of the high profile secure Web servers.

    Netscape Commerce Server

    Netscape has implemented a complete commerce strategy based on its Commerce server and browser. Additionally, Netscape has created the following resources for commercial transactions on the Internet:

    • Merchant System

    • Publishing System

    • Community System

    • Istore

    Each of these software packages is based on the Netscape Commerce server. Each streamlines the creation of an online business. These are all complete solutions tailored for different business needs. The Merchant system is designed to provide all the necessary tools and support structures for large business to create online shopping malls or large online retail stores. The Publishing system allows for online subscription-based publications.

    The Community system allows for the integration of bulletin boards, real-time chat services, and private groups. IStore is the basic package that allows merchants to create an online store with sample templates.

    The Commerce Server is designed to allow secure commercial transactions. All of the security features are built into the server and are available through the administration utilities. The Commerce Server uses the Secure Socket Layer (SSL) protocol to provide security. SSL sits between the TCP/IP stack and the HTTP protocol. There SSL can provide a number of security features including: server authentication, data encryption and verifiable data integrity.

    Who Uses Netscape Commerce Server

    The following organizations are using some or all of Netscape's Merchant System:

    Client Software

    The Netscape Commerce strategy relies on the client's use of Netscape's Web browser version 2.0. No additional software is required for the customer.

    You can find more information about Netscape's support of commercial transactions on the Internet at http://home.netscape.com/comprod/products/iapps/index.html.

    WebQuest Secure Server

    The WebQuest server by Questar Microsystems will have a secure Web server available to the public by the end of the first quarter 1996. This server will support Microsoft's security protocol PCT. Some of the advantages of the WebQuest server are price, roughly a tenth the price of the Netscape package, ease of use and installation, and its support of additional Internet protocols.

    Client Software

    WebQuest's secure server supports both Netscape 2.0 and Internet Explorer 2.0. It will also support NCSA Mosaic's secure client (version 3.0) when it is released.

    For more information on how Questar's WebQuest has implemented PCT and to download a copy of the server, visit the WebQuest home page at http://www.questar.com/webquest.htm.

    Microsoft Internet Information Server

    Microsoft's Internet Information Server supports secure transactions over the Internet through SSL and RSA encryption. Currently, Microsoft's IIS SSL only works with Microsoft's Internet Explorer 2.0.

    Microsoft is working on a suite of applications similar to Netscape's Merchant System. This suite will be a combination of: Microsoft's Merchant server, a server linked to databases, which will allow secure financial transactions; the Merchant workbench, similar to Netscape's IStore and a client "shopping utility" which will make online shopping easier and more consistent for the buyer. All these products will be available from Microsoft some time in mid-1996. Microsoft has not established pricing for these software packages, though they will probably be significantly less expensive than Netscape's current prices.

    Visit Microsoft home page at http://www.microsoft.com and follow the link to "Search" and there search for "Electronic Retailing" and "Internet Information Server."

    (c)Shopping Carts/Shopping Malls In addition to the online shopping malls discussed above, InfoHaus and the IStore, there are number of online shopping malls. The following is a short list found by using Yahoo:

    As a merchant, you have the choice of using an existing "shopping mall" for hosting your Web site or hosting your Web site. If you choose the first, the above listing will give you a place to start. Look for a "shopping mall" that supports a search engine and is easy to navigate.

    CGI Scripts

    Some companies have built their own CGI scripts that allow them to sell online. Buyers are asked to post their credit card information when buying products. This strategy is fairly easy to implement and also fairly easy to break. The best way to implement this strategy is with a secure server like Netscape's Commerce Server. That way the connection between the client and server is encrypted and secure, making fraud very difficult. The actual implementation of the CGI will depend on what resources are available with your system, PERL, C++, Visual Basic, and on the abilities of the CGI programmer.

    There is a large body of information online about CGI scripts. A good place to start is http://the-inter.net/www/future21/cgia.html.

    Alternatives

    In addition to the strategies reviewed above, there are other, in some ways simpler, ways of handling online commerce. Some companies allow people to place orders over the Internet and then deal with billing through common interfaces.

    Taking Orders (COD)

    One of the most common ways of offering products for sale over Internet is to take orders and then deliver products COD. This approach has some very distinct advantages. The interface is very simple to create. A basic htmL form that posts the order information to your e-mail account or some sort of database is easy and quick to create. Sending product COD resolves all concerns about security and fraud, by using an existing "secure" system. The other obvious benefit is that customers without checks can purchase products from you. A twist on this is to send customers a "bill" before sending out the merchandise. When the customer has paid the bill, you send out the product. These implementations are simply a carry over from mail-order catalogs.

    Establishing Accounts

    Another strategy commonly used is to require customers to establish an account with the merchant. Anyone can order over the Internet, again from a Web page form, but only those customers with an account will receive the products or services. You can require a potential customer to call you with their credit card number to establish an account, or require that they send you a check for a set amount and require them to maintain a minimum balance. A merchant using this strategy would ship only to people with established accounts. One advantage to this is existing systems are used to process transactions. People are used to giving out their credit card number over the phone. And depending on the implementation, creating an "account" is not unfamiliar to the general public.

    Summary

    The frictionless economy is on it's way. There are clearly many companies racing to develop a clean and secure interface for buying on the Internet. A standard has yet to be set, but many opportunities are available to the resourceful infopreneur.

    Merchants who opt for setting up on the Internet will likely reap many benefits in both the savings they will see and the volume of business they will transact. It can certainly be much cheaper to set up a virtual store than a real one. Your virtual store will have many of the same challenges as a "real" store. You will need to market and promote to attract customers and assure them of a safe, secure place to shop. This chapter covered a lot of material; from here, use the Net to continue your explorations and craft a solution that is appropriate for your business and vision.


    QUE Home Page

    For technical support For our books And software contact support@mcp.com

    Copyright © 1996, Que Corporation

    Table of Contents

    17 - Database Access and Applications Integration

    19 - Interactive and Live Applications