Arguably the most important part of electronic commerce occurs when buyers part with their money. To get to that point, not only do buyers have to decide they want the merchandise (an issue in all forms of commerce); they need to have confidence that the money they pour into the Internet will actually come out the other end to the merchant and not be stolen or lost along the way. Buyers also have to have confidence that the merchant is reputable and will deliver the goods as promised.
Each of these soft issues, such as trust, has a technical counterpart, such as provability. This chapter knits together the business issue of getting paid with the technical issue of how payment can be taken over the Internet.
Many industry analysts believe that the "killer application" on the Internet is electronic commerce. When people can buy something over the Net as easily as they do in a store, over the phone, or by mail, the position of the Internet as a major medium will be secure.
As a first approach to getting paid, some site owners wonder why they can't just put up a form that captures a user's credit card number and expiration date and process that information just as if it came in over the phone.
The answer, of course, is that they can. Indeed, the script in Chapter 27, "Multipage Shopping Environment," shows exactly that approach. But don't be surprised if a lot of users decline to put their credit card information over the open Net.
There is a perceived risk among many Web users that credit card numbers passed over the open Net are likely to be picked up by thieves. In fact, the information is vulnerable in at least four ways:
Most home shoppers connect to the Net using dial-up analog phone lines. The communications over those phone lines are, after all, only sound. It is theoretically possible for someone to record those sounds, play them back through a modem, and reconstruct the information (including credit card numbers).
In practice, tapping phone lines is likely to be a losing proposition for a thief. The cost of access and equipment is high compared with the likely return.
Once the user has reached a local service provider, the information travels over various digital links to reach the merchant's server. Special pieces of hardware (called packet sniffers) can be used to read the TCP/IP packets off those links.
You can set up a number of personal computers as sniffers by operating their network card in what is called promiscuous mode. If such a computer were located electronically close to a high-volume merchant, many of the packets going by would hold credit card information.
When the credit card information arrives at the merchant's server, it is processed by a CGI script and stored in a database or disk file. The server is vulnerable to attack just like any other machine on the Net.
Chapter 17, "How to Keep Portions of the Site Private," and Chapter 40, "Site Security," describe methods of increasing the resistance of a site to attack.
An often-neglected point of vulnerability is the merchant's organization itself. Just as dishonest waiters can steal credit card information at a restaurant, dishonest system administrators can do whatever they like with the file of credit card information.
Each of these points of vulnerability can be protected. Secure communications such as those afforded by Netscape Commerce Server or Secure Mosaic can protect communications from the client's desktop machine to the merchant's server.
The methods described in Chapters 17 and 40 can help protect the server itself. Threats from inside the merchant's organization can be reduced by some of the same controls that work with non-Net merchants.
Furthermore, it appears that, in practice, most thieves have not yet discovered the Internet. Newsgroups and discussion lists have asked for stories, even second or third hand, of people who actually had their credit card information stolen. There are very few anecdotes circulating.
Of course, some network security experts argue that this is exactly what you would expect if a site had been attacked by sophisticated thieves. They reason this way: if someone steals a wallet, the wallet's owner will discover his or her loss fairly quickly. To get any benefit from the theft, the thief must run the credit cards up to their limit quickly, before the cardholder notifies the credit card company to disable the cards.
But if thieves using, say, a sniffer, get access to thousands of cards, they could put a small charge on each one without triggering most of the existing alarms. In this scenario, most cardholders would never even know they had been victimized.
The most common commercial practice today is to put at least the form that captures credit card data, if not the whole Web site, on a machine running a secure server such as the Netscape Commerce Server. When users running Netscape Navigator connect to a secure form on the Netscape Commerce Server, the key in the bottom left corner of their screen changes from broken to unbroken.
Users can choose View, Document Info to see the merchant's certificate so they know whom they are dealing with. Users can then make a decision about whether or not they are willing to trust their card information to that merchant.
Of course, most users are not that sophisticated. Many users do not even check to see if they are talking to a secure server. Very few will check the server's certificate or question it if the certificate does not match the name of the merchant. And it is the rare individual who is qualified to determine whether a previously unknown merchant is trustworthy.
In theory, one of the reasons we use credit cards is so that each customer does not have to evaluate the trustworthiness of each merchant. By law, customers are not obligated to pay for merchandise they did not receive or that did not substantially conform to the description they were given.
Many credit card companies go further and offer extended warranties on products paid for using their credit card. For these reasons, the credit card companies have certain standards of stability they look for before granting merchant status to a business and allowing it to accept credit cards.
In practice, the pipeline between the merchant and the card issuer is a long one. There are several layers of resellers who have varying degrees of latitude in qualifying merchants. The fees built into credit card processing are designed to cover the card issuer's expenses in dealing with dissatisfied card holders.
With the current state of affairs, it can be hard for a new merchant, particularly one set up only to do business on the Net, to qualify for a merchant account with one of the major credit card companies. These companies want to see real bricks and mortar-to know that the merchant will physically be there to make good on any complaints.
If the Net-based merchant can qualify for an account, it is often through a low-level reseller who has marked up the transaction fees to cover the risk of dealing with a new and less tangible business.
It is significant to note, too, that the credit card companies cover any fraudulent charges made on a card if it is stolen out of a purse or wallet but have not universally agreed to extend the same protection to cards stolen off the Net. Both Visa International and MasterCard officially "discourage" cardholders from putting their card number on the Net.
Cardholders who have their card number stolen from the Net could find that the thief uses their card right up to its credit limit. If the card issuer determines that they failed to safeguard the number, the cardholder may have no recourse but to pay the bill. The credit card issuers recommend that until their own approved security is in place, merchants arrange to collect card numbers over the telephone or by mail.
Some visitors are concerned about more than the loss of their credit card information. They suspect that the merchant, the financial institution, or even a third party with a packet sniffer might track their purchases and use the information in ways they did not intend.
Every time we subscribe to a magazine, buy something by credit card, or make a long distance call, that information is stored in a database. There is a whole industry, the mailing list managers, associated with pulling the information out of these databases and assembling targeted lists for marketing.
Some people consider these lists to be useful. If I have no interest in SCUBA diving, an advertisement for a new set of tanks is junk mail to me. But if you subscribe to seven diving magazines, that same mail may be of real interest to you. Good mailing lists allow merchants to focus their mailing, reducing the amount of junk mail and lowering the merchant's cost of doing business.
Other people consider any attempt to track them or their interests to be intrusive. They would like their transactions to be anonymous. When making conventional transactions, they often use cash and would like an electronic equivalent that did not leave a trail in someone's database.
Coleta Brueck, the project manager of the U.S. Internal Revenue Service Document Processing System, described the IRS's vision for traceable transactions. For the full story, see "E-Money (That's What I Want)" by Steven Levy, at http://www.hotwired.com/wired/2.12/features/emoney.html.
Levy quotes Brueck describing the Golden Eagle tax return in which the government automatically gathers all relevant aspects of a person's finances, sorts them into appropriate categories, and then tallies the tax due:
"If I know what you've made during the year, if I know what your withholding is, and if I know what your spending pattern is, I should be able to generate a tax return for you. I am an excellent advocate of return-free filing. We know everything about you that we need to know. Your employer tells us everything about you that we need to know. Your activity records on your credit cards tell us everything about you that we need to know.
"Through interface with Social Security, with the DMV, with your banking institutions, we really have a lot of information, so why … at the end of the year or on April 15, do we ask the Post Office to encumber itself with massive numbers of people out there, with picking up pieces of paper that you are required to file? … I don't know why. We could literally file a return for you. This is the future we'd like to go to."
Not everyone is as enthusiastic about traceable transactions as Ms. Brueck.
There are also legitimate law enforcement concerns about anonymous electronic cash and complete privacy.
Wired magazine (June 1994) quotes Stewart Baker, chief counsel for the U.S. National Security Agency (NSA), as saying, "Take, for example, the campaign to distribute PGP ('pretty good privacy') encryption on the Internet. Some argue that widespread availability of this encryption will help Latvian freedom fighters today and American freedom fighters tomorrow.
"Well, not quite. Rather, one of the earliest users of PGP was a high-tech pedophile in Santa Clara, California. He used PGP to encrypt files that, police suspect, include a diary of his contacts with susceptible young boys using computer bulletin boards all over the country."
During the late 80s and early 90s, there were widespread allegations that the U.S. Justice Department put "trapdoor access" into a banking program called PROMIS from INSLAW to have access to a bank's transaction records.
For more information see "Beneath Contempt: Did the Justice Department Deliberately Bankrupt INSLAW?" in Barron's National Business and Financial Weekly, March 21, 1988; "Rogue Justice: Who and What Were Behind the Vendetta Against INSLAW?" in Barron's National Business and Financial Weekly, April 4, 1988; "The Inslaw Affair, U.S. House Report 102-857 from the House Committee on the Judiciary (September 10, 1992)"; and "Congress Backs Claims That Spy Agencies Bugged Bank Software" in Thompson's International Banking Regulator, January 17, 1994.
To their credit, the proponents of e-cash have given thought to this issue. DigiCash, the leader in anonymous electronic cash systems, points out that only the payer is anonymous, not the payee. Anonymous cash does not benefit the tax evader or the black marketeer since all their income must be turned in at the bank to be converted into conventional currency.
Credit card money can only be spent with a merchant who has been authorized by the credit card issuer. Per-transaction fees are low but tend to discourage very small transactions.
Much of the commerce on the Web is expected to be with people who may not think of themselves as merchants and who may want only a few cents per transaction. A researcher may want to charge a dollar or two to allow people to access technical papers. A poet may want to charge fifty cents for a "limerick of the day."
The needs of these people are ill-served by credit cards. They want something online that works more like, well, cash.
Electronic cash, or e-cash (also called e-money), comes in two flavors: identified and anonymous. The most common form of identified (traceable) e-cash is based on public key encryption and works like this:
Alice goes to the bank with $100. The bank accepts her money and in return gives her, for example, 100 electronic messages, each signed with the bank's private key. Anyone can verify that a message is from the bank by decrypting the signature with the bank's public key, which is widely published.
Each message contains a serial number. When Alice pays Bob, say, $12 for an item, she transfers 12 of the $1 messages to Bob, who sends them on to the bank. The bank can verify that the messages are from it and it honors them by giving Bob $12 in real currency.
The e-cash described above is identified because the bank's records show the serial numbers of each of the 100 messages that were given to Alice. When 12 of these messages come back from Bob, the bank can, in principle, tell where Alice spent her money.
Anonymous e-cash is a variation on the theme above. When she goes to the bank, Alice uses a method called blind signatures to accept the e-cash. (Blind signatures are explained in more detail later.)
Once Alice has the money, the blind signature algorithm allows her to transform it into anonymous cash. She can still give it to Bob and he (and the bank) can tell that they are legitimate, but the bank can no longer match the messages that come back with the messages they gave Alice.
Suppose that Alice (or better still, Alice's computer) picks the serial number of the electronic banknote she wants issued. If the number is large (100 digits, for example), the likelihood of it duplicating an already issued note is small.
Now, before she asks the bank to sign the banknote and without telling the bank what serial number she picked, Alice picks another random number and multiplies the banknote serial number by her random number. (The actual transformation is a bit more complex but the principle is the same.)
The bank signs the transformed banknote, so it is now money and gives it back to Alice. Alice divides the contents of the e-cash message by her secret random number and uses that message as cash. Now when Alice gives the money to Bob, he can still verify that it has a valid bank signature.
When Bob sends it to the bank, the money still verifies and the bank honors it. But because it doesn't know Alice's secret number, it can't trace the banknote back to her.
Anyone who has spent more than 30 seconds with a hard drive knows that it's easy to duplicate a file. Electronic cash is, after all, a series of messages in files, so there is nothing complex about taking that one-dollar message and making a million copies. This issue is at the heart of what is called the double-spending problem.
There are three solutions to the double-spending problem. One solution works only for identified money. If a culprit is given an electronic bank note with serial number 12345 and that note shows up more than once for deposit, the bank goes after the person to whom it issued that note.
The other two solutions work even if the money is anonymous and are called the online and offline solutions.
Anonymous online money can be verified as it is spent. (So, for that matter, can identified online money.) When Alice presents the e-cash to Bob, Bob's computer contacts the bank's computer and says, in essence, "I am being offered bank note 12345. Has anyone else cashed this note in yet?" If the bank's computer says that the note is good, Bob accepts it and presents it to the bank for payment.
But what if it's not convenient for Bob to check every note with the bank as it comes in? Can he have any protection if he accepts the note and later finds that it had already been deposited? Presumably, if the money is identified, people won't attempt this since they know they'll be caught. But what if the money is anonymous?
David Chaum of DigiCash has developed an ingenious scheme that preserves anonymity as long as the person does not attempt to double-spend but produces what amounts to an unforgeable digital confession if they do. It works like this:
When Alice goes to the bank for e-cash, her computer generates a series of random numbers. Random numbers are combined with the combined banknote serial number and blind signature and with Alice's bank account number.
Alice's computer produces enough of these combined numbers for twice the number of banknotes she needs. Thus, if she wants to buy 100 $1 banknotes, Alice's computer generates enough information for 200 such messages.
The bank randomly chooses 100 of the numbers, signs them, and gives them back to Alice. It then asks her (or actually, her computer) for the secret random numbers for the other 100 message and uses the secret numbers to read out the account number embedded in the message. If Alice is using someone else's account number, the bank knows it can take appropriate action.
Assuming that Alice has not tried to forge banknotes on someone else's account, she now applies her blind signature number again to the messages she got from the bank to make them anonymous and spends them as usual. As long as she does not double-spend, all goes well.
When she spends a note at Bob's, Bob's computer generates a random number with the same number of bits as Alice's random numbers. If Bob's random number has a one in a given position, he gets the random number for that position.
If Bob's random number has a zero in that position, he gets Alice's account number combined with the random number. As long as Alice only spends the money once, no one can get both pieces of information for a given slot.
But if Alice cheats and spends the same money at Charlie's, Charlie applies his own random number and gets a different combination of random-number/random-number-with-account-info pairs. When Bob and Charlie both deposit the same note at the bank, the odds are good that at least one slot was decoded for a random number by one seller and a random-number-with-account-info combination by the other.
The bank now uses the random number for that slot to pull the account info out of the other half and has uniquely identified Alice as a double-spender. Alice cannot claim that someone else used her account number since the bank decrypts the unused banknote messages for every customer to be sure they are using their own account ID.
Here's an example of how this scheme works on one banknote. The numbers are much smaller than usual, so we can actually see how the algorithm works.
Alice picks a banknote number of 100 and a blind signature number of 5. If she were going to generate online, anonymous e-cash, she would ask the bank for a banknote with serial number 500 (5¥100). To generate offline, anonymous e-cash, her computer generates a series of random numbers.
Let's make that number six. Let's also suppose Alice's account number is 1210 (equivalent to 0C16). (Remember, all these numbers are much smaller than the numbers really used in the algorithms.)
Table 25.1 shows Alice's six random numbers ai, in hexadecimal,
and the result of transforming her account number with the random
number. (The transform is an exclusive OR.)
The numbers above are not exposed inside the e-cash. Instead, they are used as the input to a one-way function like MD4 or MD5. The output of that function is passed to still another one-way function that serves as the basis for the bank's signature.
Let's suppose Alice spends this money with Bob and Bob chooses
the random number 0101112. Bob gets back the portion of the original
table shown in Table 25.2, which he sends to the bank when he
cashes the note.
Now Alice cheats and spends the same piece of money with Charlie.
Charlie's random number is 0000102. The results of this probe
are shown in Table 25.3. Charlie sends this table along
to the bank when he deposits the banknote.
When the double-spent money arrives at the bank, the bank puts
the two tables together to get the information in Table 25.4.
The bank has three rows (i=1, i=3, and i=5) for which both columns
are present. They compute the exclusive OR of both columns and
find the results given in Table 25.5.
If Alice had spent the money only once, her identity would have remained anonymous. But since she double-spent, her account number, and consequently her ID, are revealed.
Again, she can't claim someone used her account without her knowledge since she prepared two sets of numbers for every banknote she wanted, and the bank chose which one it would use and which one it would decode and check. (This method is formally called cut-and-choose.)
As Chaum and others envision it, neither the user nor the merchant would have any idea of the computations underlying e-cash. Users would carry a smart card or have these algorithms built into software on a desktop computer.
When users made a purchase, they would just choose an amount and send it. The merchant would press Check Money to verify that the banknote had a valid signature from the bank and then press Deposit to send the results of all these computations to the bank.
Actual software that implements many of these algorithms is available at http://www.digicash.com/ and http://www.marktwain.com/. Examples and tutorials are also available on the DigiCash site.
For more details on e-cash, read Steven Levy's article at http://www.hotwired.com/wired/2.12/features/emoney.html. Chaum's article in the August 1992 issue of Scientific American (entitled "Achieving Electronic Privacy" on pages 96-101) is available online at http://ganges.cs.tcd.ie/mepeirce/Project/Chaum/sciam.html.
There is a short, frequently asked questions (FAQ) list on e-money at http://www.ex.ac.uk/~RDavies/arian/emoneyfaq.html.
To learn more about the double-spending problem, see http://ganges.cs.tcd.ie/mepierce/Project/Double/dsarticles.html.
This section describes some of the payment mechanisms available today that are based on credit cards. The remainder of this chapter describes other methods, including Internet-based checks, e-cash, and more traditional payment mechanisms.
Secure servers are described earlier in this chapter, in the section titled "Perceived Versus Actual Risk." Their advantages are that they are close to what people are used to today. They deliver on their promise of providing hard-to-read communications from the client's browser all the way to the server software.
When combined with good security on the server machine and in the merchant's organization, secure servers can be an effective deterrent against theft of credit card numbers or other sensitive information.
The disadvantages of this approach include the fact that the merchant must still get a merchant's credit card account (which may be easy for some and complex for others) and that most secure servers (like the Netscape Commerce Server) are not free.
Note, too, that the merchant does get access to the credit card number. If the merchant has a dishonest staff member, users can get a false sense of security from the little solid key in the corner of the screen.
Finally, note that secure servers work with a limited range of browsers. The Netscape Commerce Server, for example, uses the secure sockets layer. That protocol is fully implemented in only a handful of browsers. Notable among them, of course, is Netscape Navigator, with a huge installed base.
Cybercash, Inc., offers a "digital wallet"-an application that resides on users' computers and allows them to store information about one or more credit cards. When users visit a site that accepts CyberCash, they use the digital wallet to select a credit card.
The card information is sent encrypted over the Net to the merchant (who is unable to decrypt the message and so can't read the card number). The merchant forwards the message on to CyberCash, which completes the transaction and sends the money to the merchant.
This approach has the advantage of working with all browsers and servers. CyberCash still requires that the merchant have a merchant's credit card account (which may be a problem or a burdensome cost to some Net-based merchants). The CyberCash site lists a number of banks that have issued accounts to Net-based merchants and they have experience helping merchants get accounts.
Figure 25.1 shows the CyberCash wallet.
Figure 25.1: The CyberCash wallet is an application running on a user's own computer.
CyberCash calls its affiliated systems integrators "VIPs." For details about joining its VIP program, visit http://www.cybercash.com/cybercash/vip/vipform.html. CyberCash provides both the user's wallet and the server's software (which it calls SMPS) for free.
To use CyberCash, the server sends information about the item with MIME-type application/cybercash. That MIME type should be configured on the user's browser to start the wallet. The user selects a credit card and clicks the Pay button.
When the wallet replies, the server strips off the order, digitally signs and encrypts the remaining packet, and sends it to the CyberCash server. The CyberCash server is behind a firewall. It immediately takes the packet off the Internet, decrypts it, and sends the request for payment to the merchant's bank over dedicated lines. The merchant's bank sends the request for payment to the user's bank (or to Discover or American Express, as appropriate).
Within 15 to 20 seconds, the approval or denial code is sent from the card issuer and is forwarded back to the merchant and on to the user. If the charge is approved, the merchant can send a message to the user with information on when to expect the merchandise.
Again, both server software and client software are provided free by CyberCash. Full information is available on its site at http://www.cybercash.com/.
First Virtual Holdings takes a different approach from CyberCash. The credit card number never travels over the Internet, not even in encrypted form, and the merchant doesn't need a merchant's account.
To buy using First Virtual, the user sets up an account and provides the credit card information over the telephone. Full details are available at http://www.fv.com/.
To sell using First Virtual, the merchant must have an account that is authorized for selling and must agree to pay transaction fees, which are generally about the same as credit card transaction fees.
First Virtual defines its own protocol to allow communications
between the merchant's server and the First Virtual server. Variations
are available for e-mail and the Web. Listing 25.1 shows one way
to implement this protocol. Full information and sample scripts
(in Tcl) are available on First Virtual's Web site.
| Caution |
The script in Listing 25.1 is tailored for use by the Nikka Galleria site ( http://www.dse.com/nikka/). Be sure to change it to meet local requirements such as server name, account ID, and Webmaster before trying to use it to communicate with First Virtual Holdings. |
Listing 25.1 One Way to Communicate with First Virtual
#!/usr/local/bin/perl
#@(#)checkout.cgi 1.6
# Copyright 1995-1996 DSE, Inc.
# All Rights Reserved
require "html.cgi";
# use test.card.com for test purposes; card.com for live transactions
$SGCS = "test.card.com";
# what is the name of this host
$HOST = "dse.com";
$MissingRequiredInformationPage =
"http://www.dse.com/nikka/Orders/3.MissingRequiredInformation.shtml";
$FVIdentifierButNoFVPage =
"http://www.dse.com/nikka/Orders/4.FVIdentifierButNoFV.shtml";
$FVButNoFVIdentifierPage =
"http://www.dse.com/nikka/Orders/5.FVButNoFVIdentifier.shtml";
$shippingAndHandling = "17.00";
$TaxState = "VA";
$TaxRate = 4.5; #in percent
$OwnersFVId = "test-12345xyz";
$OwnersEmail = "GWaibel\@aol.com";
$WORKS{EarthTribe} = 4500;
$WORKS{SnakeDance} = 2000;
$WORKS{TattooEye} = 2250;
$WORKS{TattooStoneBird} = 4000;
$WORKS{OnToGettysburg} = 165;
$WORKS{SpringGarden} = 125;
$WORKS{EveningStroll} = 135;
$WORKS{Ocean} = 650;
$WORKS{PrettyDay} = 135;
$WORKS{OleTimeReligion} = 95;
# set up some handy variables
$kTrue = 1;
$kFalse = 0;
if ($ENV{'REQUEST_METHOD'} eq 'POST')
{
# Using POST, so data is on standard in
read (STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
# Split the fields using '&'
@pairs = split(/&/, $buffer);
# Now split the pairs into an associative array
foreach $pair (@pairs)
{
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{$name} = $value;
}
# Check for illegal metacharacters.
if ($FORM{email} !~ /^$/ && $FORM{email} !~ /^[a-zA-Z0-9_\-+ \t\/@%.]+$/)
{
&html_header("Illegal Characters");
print "Your e-mail address contains illegal \n";
print "characters. Please notify \n";
print "the webmaster: \n";
print "<A HREF=\"mailto:morganm\@dse.com\">morganm\@dse.com</A>\n"
;
&html_trailer;
}
else
{
# check for required data
if (($FORM{name} =~ /^$/) || ($FORM{address} =~ /^$/) ||
($FORM{city} =~ /^$/) || ($FORM{state} =~ /^$/) ||
($FORM{zip} =~ /^$/) || ($FORM{workphone} =~ /^$/) ||
($FORM{homephone} =~ /^$/))
{
print "Location: $MissingRequiredInformationPage\n\n";
}
# make sure the First Virtual ID is consistent with the method of payment
elsif ( $FORM{FVId} =~ /^$/ && $FORM{payment} eq 'FV')
{
print "Location: $FVIdentifierButNoFVPage\n\n";
}
elsif ( $FORM{payment} eq 'FV' && $FORM{FVId} =~ /^$/)
{
print "Location: $FVButNoFVIdentifierPage\n\n";
}
else
{
# see if we are paying by check
if ($FORM{payment} eq 'check')
{
&sayThankYou;
&sendEmail;
}
else
{
# consider passing the FVId to First Virtual
# does the FVId even look like a valid ID?
if ($FORM{FVId} !~ /^ a-z][a-z][a-z][a-z][0-9a-z]+$/)
{
$validID = $kFalse;
}
else
{
$theResult = 'finger $FORM{FVId}\@inquiry.$SGCS';
if ($theResult !~ /account-status: active/)
{
$validID = $kFalse;
}
else
{
$validID = $kTrue;
}
}
# if it fails, tell the user
if ($validID == $kFalse)
{
print "Location: $FVIdNotValid\n\n";
}
else #we have a valid FV account
{
&sayThankYouFV;
&sendFVmail;
&sendEmail;
}
}
}
}
}
else
{
&html_header("Error");
print "<P>Not started by POST.</P>\n";
&html_trailer;
}
sub sayThankYou
{
&html_header("Thank You");
print "<P>Please print this form and mail it to the address given below.</P>\n";
print "<P>Name: $FORM{name}</P>\n";
print "<P>Address: $FORM{address}</P>\n";
print "<P>City: $FORM{city} State: $FORM{state} Zip/PostalCode: $FORM{zip}</P>\n";
print "<P>Work Phone: $FORM{Workphone} Home Phone: $FORM{homephone}</P>\n";
print "<HR>\n";
print "<P>Company: $FORM{company}</P>\n";
print "<P>E-mail address: $FORM{email}</P>\n";
print "<P>Comments: $Comments{comments}</P>\n";
print "<HR>\n";
$ThankYouWork = $FORM{Work};
$ThankYouWorkPrice = $WORKS{$FORM{Work}};
print "<P>Work: $ThankYouWork Price: \$$ThankYouWorkPrice<BR>\n";
print "Shipping and Handling \$$shippingAndHandling<BR>\n";
$ThankYouTax = &tax;
printf ("Tax \$%7.2f</P>\n", $ThankYouTax) if ($FORM{state} eq $TaxState);
$ThankYouTotal = &total;
printf ("<P>Total \$%9.2f</P>\n", $ThankYouTotal);
print "<ADDRESS>\n";
print "Nikka Marketing and Communications Group<BR>\n";
print "2035 Carolina Road<BR>\n";
print "Chesapeake, VA 23322<BR>\n";
print "</ADDRESS>\n";
print "<P>Checks may be made payable to \"Nika Marketing and Communications Group\"\n";
&html_trailer; "<P>Please print this form and mail it to the address given
below.</P>\n";
}
sub sayThankYouFV
{
&html_header("Thank You");
print "<P>Thank you for your order. Very soon you will get an e=mail\n";
print "from First Virtual asking you to confirm this transaction.\n";
print " When you enter \"Yes\", your account will be charged and\n";
print " we will arrange for your art to be shipped.</P>\n";
print "<P>You should expect your art to be delivered in two to four weeks.</P>";
print "<P>Name: $FORM{name}</P>\n";
print "<P>Address: $FORM{address}</P>\n";
print "<P>City: $FORM{city} State: $FORM{state} Zip/PostalCode: $FORM{zip}</P>\n";
print "<P>Work Phone: $FORM{Workphone} Home Phone: $FORM{homephone}</P>\n";
print "<HR>\n";
print "<P>Company: $FORM{company}</P>\n";
print "<P>E-mail address: $FORM{email}</P>\n";
print "<HR>\n";
$ThankYouWork = $FORM{Work};
$ThankYouWorkPrice = $WORKS{$FORM{Work}};
print "<P>Work: $ThankYouWork Price: \$$ThankYouWorkPrice<BR>\n";
print "Shipping and Handling \$$shippingAndHandling\n<BR>";
$ThankYouTax = &tax;
printf ("Tax \$%7.2f</P>\n", $ThankYouTax) if ($FORM{state} eq $TaxState);
$ThankYouTotal = &total;
printf ("<P>Total \$%9.2f</P>\n", $ThankYouTotal);
print "<ADDRESS>\n";
print "Nikka Marketing and Communications Group<BR>\n";
print "2035 Carolina Road<BR>\n";
print "Chesapeake, VA 23322<BR>\n";
print "</ADDRESS>\n";
print
"<P>You have elected to pay using your
<A HREF=\"http://www.fv.com/\">First Virtual</A> account\n";
&html_trailer;
}
sub sendEmail
{
#send a copy of a valid form to Nikka and the customer
open (MAIL, "| sendmail -t") || &die("Unable to open sendmail\n");
print MAIL "From: $OwnersEmail\n";
print MAIL "To: $OwnersEmail";
if ($FORM{email} !~ /^$/)
{
print MAIL ",$FORM{email}\n";
}
else
{
print MAIL "\n";
}
print MAIL "Here is a copy of your Nikka Galleria order\n";
print MAIL "Subject: Nikka Galleria Order\n";
print MAIL "Work........$FORM{Work}\t\$$WORKS{Work}\n";
$mailWorkPrice = $WORKS{$FORM{Work}};
print MAIL "Work.............$FORM{Work}\t\t\$$mailWorkPrice\n";
$mailTax = &tax;
printf MAIL ("Tax.........................\$%7.2f()\n", $mailTax) if ($FORM{state}
eq $TaxState);
print MAIL "Shipping and Handling.........\t$shippingAndHandling\n"
if ($shippingAndHandling !~ /^$/);
$mailTotal = &total;
printf MAIL ("Total......................\$%9.2f\n", $mailTotal);
close (MAIL);
}
sub sendFVmail
{
# send a 'green' message to First Virtual announcing the transaction.
# build a transaction ID. Start with the minutes.
$time = time();
$minutes = $time / 60;
$transactionID = $minutes . $$ . "\@.$HOST";
($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) =
gmtime($time);
$day = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday,
Saturday)[$wday];
$month = (January, February, March, April, May, June, July, August,
September, October, November, December)[$mon];
open (MAIL, "| sendmail -t") || &die ("Unable to open sendmail\n");
print MAIL "From: $OwnersEmail\n";
print MAIL "To: transfer@$SGCS\n";
print MAIL "cc: $FORM{email}\n" if $FORM{email} !~ /^$/;
print MAIL "Subject: websale\n";
print MAIL "Content-type: application/green-commerce;
transaction=transfer-request\n\n";
print MAIL "seller: $SELLER\n";
print MAIL "buyer: $FORM{FVId}\n";
print MAIL "transfer-id: $transactionID\n";
$mailTotal = &total;
printf MAIL ("amount: \$%9.2f\n", $mailTotal);
print MAIL "currency: USD\n";
print MAIL "description: $FORM{Work}\n";
print MAIL "payment-expected: yes\n\n";
print MAIL
"Thank you for your purchase of $FORM{Work} from Nikka Galleria on $day,
$month $mday at $hour:$min GMT\n";
close (MAIL);
}
sub tax
{
#compute taxrate x price of Work
$WORKS{$FORM{Work}} * $TaxRate * .01;
}
sub total
{
# total the price of the Work, the s&h, and the tax
$total = $WORKS{$FORM{Work}};
$total += &tax if ($FORM{state} eq $TaxState);
$total += $shippingAndHandling;
$total;
}
| Tip |
While setting up the First Virtual software, get a buyer and seller account on its test server. These accounts are free, are available almost immediately, and are only good for testing. (You can't really buy or sell with them.) Once the scripts are working, don't forget to switch back to the live server and put in the site owner's real account ID. |
Note that the script proceeds in the following steps:
When First Virtual gets the message, it sends a message to the user about the purchase, asking if it's okay to charge the user's card. Users are instructed to reply with one of the following words:
If users reply with Fraud, their account is suspended and First Virtual begins an investigation. If users ask for HumanHelp, they get, well, human help. If they repudiate the transaction by answering No, their card is not charged. But users who pull this trick too often will find their account closed.
First Virtual can be used for anything that can be sold over the Net but it's ideal for low-cost merchandise that can be delivered over the Net. For example, a merchant might sell a report for a few dollars and deliver a sample of the report to anyone who asks.
If users give a valid First Virtual account ID, they get the full report. Occasionally, a user might repudiate the transaction and steal the information, but most people are honest and the merchant makes money.
While other firms have been developing and shipping software, Visa International and MasterCard have been developing competing security standards. Visa teamed with Microsoft to develop the Secure Transaction Technology (STT). MasterCard opted for a more open approach and developed the Secure Electronic Payment Protocol (SEPP) in concert with a number of partners.
In February 1996, Visa and MasterCard announced that they had reached an agreement on a single standard, which they now call Secure Electronic Transaction (SET). Information about SET is available online at http://www.visa.com/.
With agreement at last, it seems reasonable for browser vendors to begin to incorporate the technology into their products by 1997. The SET standard is open-a full specification is online. Once the technology is in place with the two major card issuers, other card-issuing companies are likely to use the same technology.
Tens of millions of people do not have credit cards. Many others have cards that are at or close to their credit limit. Still others prefer to use credit only for emergencies. These people often prefer to "write a check" for their Internet purchases. Several companies make this possible, discussed next.
General information about the CheckMaster Corporation is found at http://www.checkmaster.com/. CheckMaster's main product line is solutions for the Magnetic Ink Character Recognition (MICR) industry-that is, check-printing companies. Details on its Internet check-writing product, the InstaCheck Payment System, are available at http://www.instachecks.com/.
Using the CheckMaster system, users fill out a secure form on its server, providing all the information associated with a check. CheckMaster then prints the checks on its printer and sends them to the merchant. CheckMaster can also send an image of the check to the merchant and sell the merchant the materials that allow the check to be printed on the merchant's laser printer.
The Intell-a-Check Corporation offers a service like CheckMaster's. Its Web site, http://www.icheck.com/, lists an impressive array of references, including Chrysler Credit, United States Cellular (at several locations), and Consolidated Edison of New York.
NetCheque and its e-cash counterpart, NetCash, are research protocols developed at the University of Southern California. NetCheque is currently online with test accounts and is expected to be licensed and available for commercial use by 1997. Full details, including information on its mailing lists, are available at http://gost.isi.edu/info/NetCheque/.
NetBill is a research initiative at Carnegie-Mellon University (CMU). In February 1995, CMU and Visa announced that they were jointly moving NetBill into a precommercial trial, using the banking services of Mellon Bank of Pittsburgh.
NetBill is particularly well-suited for very small transactions in which the merchant wants to charge just a few cents. Traditional payment mechanisms have a high cost per transaction and aren't cost-justified until the purchase price is at least several dollars.
Although not precisely a check-writing system, NetBill is based on the same credit-debit model as a checking account.
Details on NetBill are available at http://www.ini.cmu.edu/netbill/.
Earlier in this chapter, we described a variety of e-cash solutions. DigiCash offers an anonymous online system developed by the originator of the major concepts in the field.
DigiCash (at http://www.digicash.com/) is the quintessential provider of e-cash services. David Chaum of DigiCash holds many of the patents related to this technology and is one of its most zealous advocates. DigiCash sells e-cash products for computer networks under the trade name ecash.
During its trial period, DigiCash offered exchanges denominated in CyberBucks. Since October 23, 1995, the Mark Twain Bank in St. Louis, Missouri, has been offering e-cash accounts in U.S. dollars. (EUnet of Finland also offers accounts in Finnish marks.)
To accept e-cash through DigiCash, the merchant must get an executable for its server. Executables are available for
Details on how to set up the shop, along with sample Perl scripts,
are available on the DigiCash Web site. Similar instructions are
available at http:/www.marktwain.com/ecash/.
| Caution |
If your server runs on Solaris or BSDI, you must get perl5. |
| Caution |
Sites running DigiCash's programs can both accept and pay out electronic money. If the shop is connected to a real bank (this is, it is denominated in real money), be sure to set a password. |
NetCash is the e-cash service from the University of Southern California, the same group that is developing NetCheque. Like NetCheque, NetCash is a research initiative that is now available for commercial licensing. Commercial offerings by 1997 seem likely. More information is available at http://gost.isi.edu/info/netcash/.
MONDEX is a European e-cash system based on smart cards. The system has seen trial use in the U.K .and has reportedly worked well. Large-scale trials with over 700 retailers are now under way in Swindon, a large city about 70 miles from London.
For more information, visit http://www.mondex.com/mondex/home.htm.
For many companies, there is little need to handle transactions online. Their product is delivered by the postal service or other nonelectronic means, so the customer is going to have to wait at least a day for fulfillment. These companies have decided that less sophisticated payment mechanisms can still be effective.
Many companies are already set up to do business by purchase order (PO). When an existing customer contacts them by the Web and places an order, they enter a PO number. Since the merchandise will be sent to the shipping address on file, there is little chance of theft and little incentive for a criminal to enter fraudulent orders.
To prevent even the small possibility that a malicious user might enter false orders, some companies require users to enter a password with the order. Users often resist having to remember a different password for every vendor, however. A better approach might be the one used by Computer Literacy Bookshops of San Jose, California (http://www.clbooks.com), which has developed a finely tuned, account-based system.
To set up a new account, Computer Literacy's customers are asked to fill out a preregistration form and send it in by fax or mail. Computer Literacy is careful to always ship to one of the addresses on file and never accept changes to the customer's profile over the phone or by the Internet.
The orderform.cgi script discussed in Chapter 27, "Multipage Shopping Environment," prints out a hardcopy of the order. Users are allowed to pay by mail or fax by sending a copy of the order with their check or credit card information. They can also refer to the printout while placing a telephone order.
Many kinds of merchandise are easily sent by COD. For a small charge, most freight companies (such as the U.S. mail or the overnight air freight services) deliver on a COD basis. For small businesses that have not yet established a merchant's credit card account, this can be an acceptable solution.
The Internet's killer application is likely to be electronic commerce and at the heart of electronic commerce are payment mechanisms. An effective Web site will accept payment in many different forms.
Some users will prefer to pay by credit card, so the site owner may want to put a form on a secure server or to accept payment by CyberCash and First Virtual Holdings. Advanced users will bring e-cash, so the site may want to sign up with one of DigiCash's issuers such as Mark Twain Bank.
Other users prefer not to use credit cards but may not be ready for e-cash. These users may be willing to give their check information to the site and pay by electronic draft.
Finally, regular customers may want to establish an account using the model of Computer Literacy Bookshops and not have to worry about providing sensitive information over the Internet.