Credit Card Transactions

Real World and Online

Written By: Keith Lamond

Edited By: Deborah Whitman

Copyright © 1996 by Keith Lamond
Please read copyright notice


Until I started doing research for this report, I never thought about what was involved in making a credit card purchase. Most of us use credit cards frequently. We charge our meals when dining out, pay for our gas at the pump, and purchase large, and sometimes small, retail ticket items with our credit cards. But we never think, or even care, about the process running in the background that lets us make these purchases. What actually happens when the merchant runs our credit card through their Point of Sale terminal? Who is actually authorizing the charge payment? What did the merchant need to do to be able to handle credit card transactions?

My original intention was to show how credit card payments take place over the Internet. A major portion of this paper does focus on the payment methods for online credit card transactions both currently in place and in the process of being developed. The online payment portion of this paper focuses on the payment methods developed by First Virtual and CyberCash, and the proposed SET standard from MasterCard and Visa. However, it was suggested to me by my research advisorBrad Cox Ph.D., that by only researching the Internet payment protocols, I was missing a big part of the overall picture. These payment protocols handle getting credit card payment data from the buyer to the acquiring bank which will processes the transaction for the merchant. They do not dictate how the acquiring banks handle a credit card transaction, nor do they describe the relationship the merchant needs to have with the acquiring bank to process the transaction. This information is needed to have a complete picture of how credit card transactions work, both in the real world and online. Therefore I expanded my research to include all the steps in a credit card transaction, not just what takes place over the Internet.

I have broken this document into two main sections: an overview of the credit card industry, and a discussion on credit card transactions that take place over the Internet. The overview section examines credit card industry terminology, the process involved in becoming a credit card accepting merchant, and a quick overview of the events involved during a typical credit card transaction. The Internet transaction section reviews several methods for performing credit card transactions online. A breakdown of the events surrounding a transaction is included with each of the major online payment methods.

Since this document is written for viewing on the WWW, I have decided to use the conventions of the medium. For the most part, references within this document appear as links to the actual site that the information came from. I revert to customary referencing when citing non-WWW based sources. A bibliography of all sources appears at the end of this report.

Credit Card Industry Terms

One of the first things that needs to be accomplished when looking at a new area, is to become familiar with the associated terminology. As with any other area, the credit card industry has its own vocabulary which needs to be understood to fully comprehend what is taking place.


The terminology defined above is only a small amount of the vocabulary of the credit card industry. However, these are the terms you should know to be able to understand this report. Simply reading the definitions above starts to provide you with a little insight into the credit card industry.

Attaining Merchant Status

Retail and service based businesses that cannot accept credit card payments are at a disadvantage against their competitors. In the United States alone, we are spending 250 billion dollars a year with credit cards [Attard, 93]. It is no wonder that businesses want to accept credit cards, even though it means paying a percentage of each credit card sale to the acquiring bank or processor.

Attaining merchant status can be hard for small businesses, especially if they are home-based or sell by mail order [Attard, 93]. Banks are afraid of extending merchant status to businesses that present too much risk, and home-based and mail order business are perceived as high risk [Attard, 93]. Banks are afraid that an at risk business will not be able to handle any chargebacks that hit their account. If the merchant cannot handle a chargeback, the bank or ISO that processed the credit card will have to absorb the loss [Attard, 93]. In fact, VISA will penalize a bank if they have a merchant account that has more than 1 percent chargeback of their sales [Attard, 93].

Performing a search on the web for "credit card" or "merchant status" will lead to a number of pages claiming that they can obtain merchant status for your business. Small businesses must be cautious because there are many con-artists out there who offer to help a business gain merchant status and then walk away with the processing fee never to be heard from again [Attard, 93]. If you look at the credit card processing companies that advertise online, you will see that discount rates, transaction fees, and equipment sale/lease prices can vary widely. From what I have seen during my research, I would advise anyone trying to obtain merchant status to be careful. Shop around and read the fine print, especially if you are unable to open an account with an acquiring bank.

Here are some sites offering merchant status or credit card processing services. I do not endorse or discourage the use of any these banks or companies' services. I am only providing them as an example of what you will find out there.

Payment process Overview

From the information presented in the preceding sections, we can start to piece together what is occurring during a credit card transaction. We know that merchants have a relationship with either an acquiring bank or independent sales organization, through which they have their credit card transactions processed. The section on industry terminology shows us some of the fees involved in this process. Merchants must pay the acquiring bank or ISO a discount fee based on the total amount of the sale. Likewise, the acquiring bank or ISO must pay the card issuer an interchange fee when they process the sales draft from the merchant.

I talk about piecing information together because that is what I needed to do to generate an overall view of a "normal" credit card transaction. There was no one source that I found which presented the whole picture of how things work. In fact, most of the material I read treated the interaction between an acquiring bank and card-issuing bank as a black box. The descriptions only cover the starting point where the acquiring bank gets an authorization or sales draft from the merchant, and the final point when the acquiring bank sends an approval or authorization code back to the merchant.

I was able to find bits and pieces that led me to create the picture I present below. The CyberCash site provides a step-by-step walk-through of a secure payment which shows the acquiring bank contacting the card-issuing bank for authorization. A conversation I had with a representative from Card Establishment Services, Rosemary Cox, brought out the fact that a hold is placed on the cardholder's account when an authorization is done, for the amount the authorization was requested. This hold guarantees that enough credit will remain when the actual sales draft is processed. Several sites, including this Merchant FAQ, mentioned that acquiring banks and ISOs provide the merchant with a merchant ID and a separate terminal ID for each point of sale device they will use. Each of these pieces of information led me to the overview shown below.

Here is one caveat I must tell you before I present my overview of the credit card process. I am sure there are holes in the picture I present, since it has been cobbled together from the bits and pieces I was able to find during my research. This overview shows what I believe happens during a "normal" credit card transaction. I discuss how authorization of a retail sale through a point of sale unit proceeds. Many variations exist on this process. Not every merchant processes their credit card sales electronically. For example, if you look at the First Union merchant services, you will see that they offer both paper and electronic processing of credit card transactions.

Steps involved in a normal credit card transaction:

  1. Merchant calculates the amount of purchase and asks buyer for payment
  2. Buyer presents merchant with a credit card.
  3. Merchant runs credit card through the point of sale unit. The amount of the sale is either hand-entered or transmitted by the cash register.
  4. Merchant transmits the credit card data and sales amount with a request for authorization of the sale to their acquiring bank.
  5. The acquiring bank that processes the transaction, routes the authorization request to the card-issuing bank. The credit card number identifies type of card, issuing bank, and the cardholder's account.
  6. If the cardholder has enough credit in their account to cover the sale, the issuing bank authorizes the transaction and generates an authorization code. This code is sent back to the acquiring bank.
  7. The acquiring bank processing the transaction, and then sends the approval or denial code to the merchant's point of sale unit. Each point of sale device has a separate terminal ID for credit card processors to be able to route data back to that particular unit.
  8. A sale draft, or slip, is printed out by the point of sale unit or cash register. The merchant asks the buyer to sign the sale draft, which obligates them to reimburse the card-issuing bank for the amount of the sale.
  9. At a later time, probably that night when the store is closing up, the merchant reviews all the authorizations stored in the point of sale unit against the signed sales drafts. When all the credit card authorizations have been verified to match the actual sales drafts, the merchant will capture, or transmit, the data on each authorized credit card transaction to the acquiring bank for deposit. This is in lieu of depositing the actual signed paper drafts the with the bank.
  10. The acquiring bank performs what is called an interchange for each sales draft, with the appropriate card-issuing bank. The card-issuing bank transfers the amount of the sales draft, minus an interchange fee to the acquiring bank [Baughn, 88] .
  11. The acquiring bank then deposits the amount of the all the sales drafts submitted by the merchant, less a discount fee, into the merchant's bank account.

Diagram of credit card transaction

The overview presented above is far from complete. It does not cover the role of the financial networks, nor of the bankcard associations. Also, it is geared towards Visa and MasterCard transactions. There is no card-issuing bank with American Express and Discover. These shortcomings aside, the sequence of events outlined above provides a good overview of the credit card payment process. It will also give you something to look back at as I discuss methods for performing online credit card transactions. You will find that the CyberCash and SET online payment schemes try to match the process I outline above.

Online Credit Card Transactions


It seems natural that online commerce would be done with credit cards. No physical paper needs to be passed unlike cash or checks. We simply type our credit card number into the merchant's World Wide Web (WWW) page payment form and wait for our purchase to be shipped to us. The only thing that needs to pass between the merchant and the buyer is the credit card number. The problem is, it's not that simple.

People have some legitimate fears about giving their credit card number out over the Internet. It is an open network without any basic security provisions built in. Unless a secure server is involved, one that uses SSL or S-HTTP for transporting data, data passes between the browser and the server unencrypted. Because of these fears, methods are being developed to make purchasing products online more secure.

The first attempt at making online credit card transactions secure was to take the transaction off-line. Many sites will allow you to call in your credit card number to a customer support person. This solves the problem of passing the credit card number over the Internet, but eliminates the merchant's ability to automate the purchasing process. An employee needs to be available 24 hours a day to take phone calls from buyers. Also, many potential customers that visit the net only have one phone line. This means they need to log off the Internet in order to actually make a purchase.

The next method that was developed, which is currently used by many sites, is hosting the WWW site on a secure server. A secure server is one that uses a protocol such as SSL or S-HTTP to transmit data between the browser and the server. These protocols encrypt the data being transmitted, so when you submit your credit card number through their WWW form it travels to the server encrypted. This method does help ease people's fear, but it still does not go far enough for many people to feel comfortable using their credit card online.

It was apparent that for online commerce to flourish a truly secure means of making payment needed to be developed. This report describes three systems for secure credit card transactions online which should meet this need. Two of these fully operational, First Virtual's and CyberCash's payment systems, and one, the SET protocol, is currently being developed by MasterCard and Visa. I examine how credit card transactions are handled by each system, and discuss their advantages and disadvantages from both a buyer's and a merchant's viewpoint.

First Virtual Holdings

First Virtual was one of the first Internet payment systems to be available to the public, becoming fully operational in October of 1994. A main goal of this company was to create an Internet payment system that was easy to use. Neither buyers nor sellers are required to install new software, (though automated sale processing software is available). If you have access to Internet email, you can sell or buy over the Internet using the First Virtual System.

The First Virtual payment system is unique in that it does not use encryption. A fundamental philosophy of their payment system is that certain information should not travel over the Internet because it is an open network. This includes credit card numbers. Instead of using credit card numbers, transactions are done using a First VirtualPIN which references the buyer's First Virtual account. These PIN numbers can be sent over the Internet because even if they are intercepted, they cannot be used to charge purchases to the buyer's account. A person's account is never charged without email verification from them accepting the charge.

Their payment system is based on existing Internet protocols, with the backbone of the system designed around Internet email and the MIME (Multipurpose Internet Mail Extensions) standard. First Virtual uses email to communicate with a buyer to confirm charges against their account. Sellers use either email, Telnet, or automated programs that make use of First Virtual's Simple MIME Exchange Protocol (SMXP) to verify accounts and initiate payment transactions.

The following steps occur during a sale when using the First Virtual payment system:

  1. Merchant requests buyer's First VirtualPIN (usually through a form on a WWW page).
  2. Merchant can then check whether the VirtualPIN actually belongs to a real First Virtual account that is in good standing. Merchants can verify accounts by using the following programs; Finger, Telnet, email, or the FV_API utility.
  3. The merchant then initiates a payment transaction through First Virtual. This payment transaction is initiated by sending the following information either by email, Telnet, or a SMXP enabled program to First Virtual;
  4. First Virtual generates an email request to the buyer to confirm the sale. This email request contains the following sale information:
  5. Buyer confirms sale by sending a YES response to back to First Virtual
  6. First Virtual sends a transaction result message to the merchant, indicating whether the buyer accepted the charges.
  7. After a waiting period, (91 days after buyer's credit card has been charged), the amount of the sale minus transaction fees are directly deposited into the merchant's account.

The First Virtual payment system has several advantages and disadvantages over other payment systems used on the Internet.



I strongly urge that anyone interested in learning more about First Virtual visit their WWW site. It contains detailed descriptions of everything involved plus the forms necessary for opening an account. They have also recently published a paper discussing their first year on line, Perils and Pitfalls of Practical CyberCommerce.


CyberCash has been servicing credit card transactions over the Internet since April 1995. It has strong ties to the current credit card processing infrastructure, through Bill Melton, a founder of Verifone, as one of its fathers. The use of their payment system has grown tremendously over a year. CyberCash claims that they process thousands of transactions a day, they can send payment transactions to 80% of the banks in America, and to have distributed over 400,000 copies of CyberCash Wallet software to buyers who use their system.

It is important to note that CyberCash is not a credit card processing company. Unlike First Virtual, they do not transfer funds into the merchant's account. CyberCash sells safe passage over the Internet for credit card transaction data. They take the data that is sent to them from the merchant, and pass it to the merchant's acquiring bank for processing. Except for dealing with the merchant through CyberCash's server, the acquiring bank processes the credit card transaction as they would process transactions received through a point of sale (POS) terminal in a retail store.

The CyberCash payment system is centered around the CyberCash Wallet software program, which buyers use when making a purchase. This program must be downloaded and installed on the buyer's machine before they can make a purchase. This program handles passing payment information, encrypted, between the buyer and the merchant.

Once a potential buyer has obtained the CyberCash Wallet and installed it, there are still a few steps to take before it can be used. First, a buyer needs to create a persona or wallet ID which is a string of characters which identify the wallet, and a password. These are then registered with CyberCash. Buyers are allowed to create more than one wallet ID, each with its own password. Secondly, they must bind at least one credit card to the wallet. Binding a credit card entails entering pertinent credit card processing information such as credit card number, expiration date, shipping address and phone number. This information is then registered with CyberCash. Buyers can bind multiple credit cards to the wallet. Once the wallet ID is established, and at least one card has been bound, the buyer is ready to start purchasing.

To be able to accept payment using the CyberCash system, merchants must do two things. First, the merchants must install the CyberCash Internet Payment Software (SMPS). This software allows the merchant to interface with both the CyberCash buyer, or Wallet software, and CyberCash's servers. Secondly, the merchant must establish a merchant account with an acquiring bank that supports Internet transactions using CyberCash's Secure Internet Payment System. CyberCash can only communicate with banks they have an agreement with. The requirements for accepting payments through CyberCash are provided in detail in CyberCash's How to become a CyberCash Merchant document.

Steps to a credit card purchase using CyberCash's payment system:

View diagram of payment system (40K from CyberCash's site)
  1. The buyer indicates that they want to purchase an item from the merchant's WWW site by clicking on the CyberCash pay button.
  2. The merchant's SMPS software sends an invoice to the buyer's CyberCash Wallet software.
  3. The buyer selects a credit card from the ones bound to their wallet and clicks OK.
  4. The Buyer's CyberCash Wallet then digitally signs and encrypts the invoice and credit card information with the key assigned to that Wallet-ID. The encrypted packet is then sent to the Merchant's SMPS software.
  5. The merchant software adds information to the payment packet requesting that either the credit card payment be authorized or authorized and captured.
  6. The merchant's SMPS software digitally signs and encrypts the payment packet with their CyberCash key. The packet is then sent to the CyberCash server.
  7. CyberCash's server moves the packet to a machine that resides behind their firewall and off the Internet. CyberCash then decrypts the message and checks to make sure that the merchant has not tampered with the original invoice agreed upon by the buyer.
  8. The credit card information, with the merchant's request (authorize or authorize and capture), is encrypted using hardware that banks use for encrypting financial data. This information is sent over dedicated lines to the merchant's acquiring bank.
  9. The merchant's acquiring bank then processes the merchant's request as it would any other credit card transaction. It forwards the request through the card associations network to the card issuing bank.
  10. The card-issuing bank sends an approval or denial code back to the acquiring bank. The acquiring bank then sends this code to CyberCash.
  11. CyberCash sends the merchant a message indicating success or failure of the credit card payment transaction. This message is of course sent encrypted.
  12. The merchant's SMPS software then sends a message back to the buyer's CyberCash Wallet indicating success or failure of the payment transaction.

For an extremely detailed version of this process read
RFC1898 - CyberCash Credit Card Protocol version 0.8

As with First Virtual, the CyberCash system has its own set of advantages and disadvantages.



CyberCash is one of the pioneering companies in Internet payment systems. They currently have little competition in handling credit card transactions over the Internet. This will change. The release of the SET protocol (see below) will make it easier for other companies to provide Internet credit card payment systems. CyberCash is reacting to this by expanding their operations to include other types of Internet payment services including digital cash (e-cash) and micropayments.

CyberCash will support the SET protocol, once it is released. They have always stated that they would support open standards for credit card processing once they existed. In fact, CyberCash is one of the companies working on developing the SET Protocol. SET capabilities will be added to their current software, and they also plan on selling SET gateway services to acquirers [Eastlake].

SET (MasterCard/Visa)

SET stands for Secure Electronic Transactions and is a proposed standard for performing credit card transactions over the Internet. It is being developed jointly by Visa and MasterCard, with technical assistance from various Internet, information systems, and cryptology companies such as Netscape, IBM and VeriSign. With these names behind it, in the future SET may very well become the dominant method for paying by credit card over the Internet.

MasterCard and Visa are developing SET as a license-free protocol for credit card transactions over the Internet. Even though it is being developed by MasterCard and Visa, the protocol can be used by any type of credit card such as American Express or Discover. It is important to note that SET is still a work in progress. Visa and MasterCard have released drafts of both the business and technical specifications of SET for public comment. MasterCard states that testing of SET should start in the second quarter of 1996, and it should be available for use by the fourth quarter.

There are several goals they want to achieve by creating this protocol. First, they want to create a simple, inexpensive way for merchants to conduct credit card sales over the Internet. Second, they want to produce a protocol for processing credit card transactions that would have little impact on the existing financial infrastructure. Third, the SET protocol will allow software vendors to produce credit card payment software that will interoperate. Also, by being an open, license-free standard, SET will create a level playing field and insure competition among software vendors. This should keep costs down for merchants and financial institutions interested in processing credit card payments over the Internet.

On the surface, the SET protocol looks very similar to the CyberCash payment system. Merchants and buyers will both need software which follows the SET protocol in order to use SET for credit card transactions. Also, acquiring banks process credit card transaction requests delivered to them through SET in much the same way as the process requests coming through a point of sale terminal. Merchants can request the same type of transactions (authorize, authorize and capture, etc..) as they can through CyberCash.

There are differences between CyberCash and SET. CyberCash takes an active role in processing each credit card transaction that flows through their system.. CyberCash's server sits in between the merchant and the acquiring bank. It verifies the identity of the buyer and the merchant involved in the transaction. The server also handles the translation from a CyberCash format for transaction data to the format used by the acquiring banks. With SET, There is no single company which will be responsible for processing the transactions. The task of translation from SET request format to the format used by acquiring banks is done by the SET payment gateway. These gateways will either be run by companies contracted by the acquiring banks to do so on their behalf (most likely), or by the acquiring banks themselves. Identity verification of buyers, merchants, and acquiring banks is not handled by a centralized server. SET uses a system of certificates for party verification. Certificates are like the stamp a notary public places on a document to confirm the signatures on it. Certificates are issued by a trusted entity or "certificate authority" that can vouch that the party presenting a digital signature is who they say they are. The certificate shows that the signature has been proven to belong to the party in question. These certificates are passed between the buyer's, merchant's, and acquirer's payment gateway software to prove that each entity involved in the transaction is who they claim to be. For a fairly understandable and detailed explanation of how certificates work within the SET protocol, I advise the reader to download a copy of the SET business specifications.

The SET payment process is slightly more complicated than the others discussed in this paper because of the need to pass public keys between parties and verify certificates during the transaction. The payment process outlined below follows the outline set forth in the SET business specifcations. It shows a merchant requesting authorization of the credit card transaction at the time of sale, and then requesting the actual capture (charging the account) at a later time. The document does state that SET allows for the capture of the credit card charge at the same time of authorization. However, I think they wanted to present a case which closely reflects the sequence of events that takes place under credit card transactions conducted through normal retail channels.

Steps in making a credit card purchase using the SET protocol:

  1. The buyer indicates that they are interested in making a credit a card purchase.
  2. The merchant's system generates and sends the buyer an invoice for the purchase.
  3. The buyer selects a VISA or MasterCard credit card for payment from the ones they can use with their SET payment software.
  4. The buyer's software initiates the payment process by sending a request to the merchant's software for both their encryption public key and the public key of the payment gateway (acquiring bank's system) that the merchant uses. The request indicates the type of credit card the buyer will use, as a merchant may use different payment gateways for different types of cards (probably not).
  5. The merchant's software generates a response to the request and replies back to the buyer's software. This response includes:
  6. The buyer's software then verifies the merchant's and payment's gateways
  7. The buyer's software generates two packets of information to send back to the merchant, the Order Information packet (OI), and the Purchase Instructions (PI) packet. Each packet is encrypted separately. The PI is encrypted with the payment gateway's public key since the merchant is not meant to have access to it.
  8. The buyer's software transmits the OI and PI to the merchant.
  9. The merchant's software checks the message from the buyer with the OI and PI for any tampering. If no tampering is found, the software starts the process of requesting authorization from the merchant's acquiring bank.
  10. The merchant's software generates an authorization request for the credit card payment request. Included in this request is the transaction identifier that the merchant generated at the beginning of the payment process.
  11. The merchant sends to the payment gateway of their acquiring bank a message encrypted using the payment gateway's public key. This message includes the following:
  12. The payment gateway then decrypts the message and its various components such as the PI from the buyer. It checks the various parts of the message for any tampering. These checks include:
  13. The payment gateway then sends a request for payment authorization to the buyer's credit card issuer through customary bankcard channels, i.e.. the same as the acquiring bank would request authorization for any typical credit card transaction.
  14. The issuing bank sends back an approval or denial response and code to the payment gateway in response to the authorization request. This happens over regular bankcard networks.
  15. The payment gateway generates an authorization response message to be sent back to the merchant. This message includes:
  16. The payment gateway encrypts and sends the authorization response message back to the merchant's software.
  17. The merchant's software decrypts the authorization notice from the payment gateway. It examines the notice to find out if the request was approved or not. It then stores the authorization response and capture token sent by the payment gateway for later use when capturing the sale.
  18. If the transaction is approved, the merchant's software then creates a purchase response message which is sent to the buyer's software. This message informs the buyer that payment was accepted and that the product or service that they purchased will be delivered.
  19. The buyer's software processes the purchase response message and informs the buyer that payment was accepted.
  20. At a later time, the merchant's software generates a capture request message to send to the payment gateway. This request includes the capture token (optional), transaction ID, and authorization information. The sequence of events surrounding the capture are very similar to steps 13 - 15 of the authorization process.

It is important to remember that steps 4 through 19 of this process will happen in a matter of seconds. This is the sequence of events surrounding a "normal" credit card transaction. These transactions can vary depending on the circumstances. SET allows for variations such as performing the authorization and capture at the same time for merchants that require real time processing.

The SET protocol provides the following advantages and disadvantages over other payment systems:



With MasterCard and Visa putting their weight behind SET, it should probably become the dominant method of doing credit card transactions over the Internet. Companies are already starting to develop software to process SET transactions for buyers, merchants and acquiring banks. In PCWEEK ONLINE, an article mentioned that IBM will be unveiling their NetCommerce system, which will include software for buyers, merchants, and banks to process SET transactions.


This is the section of the report where I am supposed to summarize everything that went before. I have presented to you the information I learned about the credit card industry, and have tried to link the pieces I found together in some way that makes sense. Also, I described in some detail, the three major credit card payment schemes for the Internet: First Virtual's, CyberCash's, and MasterCard's and Visa's SET protocol. Okay, enough summary.

You have read my report and have taken from it what you will. I feel I will have done my job if the next time you buy something with your credit card, you stop and think about what's happening. Hopefully the next time your are on the Internet and you come across First Virtual or CyberCash you will be able to feel that you understand how they work. And, I hope you leave with questions, that you found the information interesting enough to want to learn more. Go for it.

I have tried to present the material in this report in an objective matter. Now I want to be totally subjective and give you my opinion. First, I would feel totally safe using my credit card with any of these methods. They all provide a secure means to pay for what you purchase online. The thing that is holding back commerce on the Internet at the moment is not how safe is it, but whether there is anything worth buying. That's a subject for another paper.

After looking at these three methods, I have to say that I like what First Virtual has done the best. Where both CyberCash and SET have developed high tech solutions using the latest cryptology techniques, First Virtual relied on the tried and true. They built their system on long standing, stable protocols used on the Internet; SMTP mail and MIME. Their system is so simple, it's almost elegant.

I like what First Virtual has done for an even more important reason. They have opened up the world of Internet commerce to virtually everyone. Anyone can use First Virtual to sell their wares on the Internet. They do not screen merchants. With CyberCash and SET, a person who wants to sell on the Internet must have a relationship with an acquiring bank or ISO. If you are small or just starting out, this relationship can sometimes be impossible to establish. With First Virtual, I can put the pictures I shoot in my spare time on the web and see if any sell. Without them, I wouldn't even think of trying it. First Virtual's policy allowing anyone be a seller appeals to the entrepreneur in me.

Appendix - Related Topics

This report focused on a narrow section of payment systems for Internet commerce: credit card payment systems. These systems are the most established methods for making purchases online, however, they are not the only ones. New payment methods for the Internet such as e-cash and micropayments are being developed. A picture of Internet commerce is not complete without a look at these emerging payment schemes.

I do not plan on providing an in-depth review of these emerging payment systems. I will however, provide you a starting point for finding this information yourself.


E-cash or electronic cash is digital money that you use to make online purchases. Consumers interested in shopping with e-cash have special software on their system that allows them to download money from their bank account into their cash wallet on their computer. When making a purchase, they exchange this downloaded money with the merchant for the product they want to buy. The merchant then redeems this money at a bank that accepts e-cash deposits.

There are many companies looking into providing e-cash payment systems. In fact CyberCash states on their home page that they are developing a digital cash system. However, only one company that I know of has an actual electronic cash product out on the market: DigiCash. DigiCash does not actually sell e-cash products to consumers. Their business model for e-cash is to license the technology to banks, which will host e-cash accounts for merchants and consumers.

Two banks currently offer e-cash accounts to consumers and merchants. The first bank to offer e-cash accounts was the Mark Twain bank of St. Louis Missouri. As of March 1996, EUNet of Finland has also started offering e-cash accounts (warning - their home page is mostly in Finnish).


One of the latest buzzwords on the Internet is micropayments. Currently, the way many WWW sites make money is from advertising. The content on their pages is free. The prevailing wisdom in the Internet community is that net-surfers are unwilling to pay for content. The concept behind micropayments is that if the fee for content was low enough, people would not mind paying for it. (By low, I mean 1, 10 or 15 cents a page.) Current payment systems are not set up for handling these types of transactions. The fees associated with processing credit card sales are higher than the actual payment under these circumstances.

Carnegie-Mellon University is currently testing a new payment they developed called NetBill. NetBill is an Internet payment system designed to deal with low-cost item transactions; i.e. micropayments.

CyberCash is also developing a micropayment system for Rocket Science Games. Rocket Science plans on developing a pay-as-you-play Internet arcade using CyberCash's micropayment system.


For this report, I have used documents available in various media types. These types include: books, Word documents published on the web, Interviews, and actual WWW pages. In order to make these reference materials easier to find, I have grouped them according to media type.


Attard, Janet: The Home Office and Small Business Answer Book, Henry Holt and Company, New York, 1993.

Baughn, William H.; Thomas I. Stores, Charles E. Walker: The Bankers' Handbook, Dow Jones-Irwin, Homewood Ill., 1988.

Mandell, Lewis: The Credit Card Industry, Twayne Publishers, Boston, 1990.

Rosenberg, Jerry M.: Dictionary of Banking, John Wiley & Sons Inc., New York, 1993.


Brad Cox Ph.D., professor at George Mason University

Rosemary Cox, an employee of Card Establishment Services

Donald E. Eastlake 3rd, an employee of CyberCash

Word Documents (located on the web):

MasterCard and Visa, Secure Electronic Transaction (SET) Specification Book 1: Business Description, Feb 23, 1996. Note - Only current version of document available

MasterCard and Visa, Secure Electronic Transaction (SET) Specification Book 2: Technical Specifications, Feb 23. 1996. Note - Only current version of document available

WWW sites and pages:

Carnegie-Mellon Univ.: The NetBill Project,

CyberCash: CyberCash Home Page,

CyberCash: Secure Internet Credit Card Payment,

CyberCash: CyberCash Software,

CyberCash: How to become a CyberCash Merchant,

Eastlake 3rd, D.; B. Boesch; S. Crocker; M. Yesil (all CyberCash employees): RFC 1898 - CyberCash Credit Card Protocol Version 0.8,

Del West's Market Market: Merchant Credit Card Info,

DigiCash: DigiCash home page,

EMS Nationwide: EMS Nationwide,

EUNet Finland: EUNet,

First of Omaha: First of Omaha Merchant Processing,

First Union: First Union's Merchant Sales and Services,

First USA: Welcome to FirstUSA - Merchant and Financial Services,

First Virtual: FV: Home Page,

First Virtual's founding members: The Lessons of First Virtual's First Year,

Borenstein, N.; N. Freed: RFC 1521 - MIME,

Rose, T Marshall; Nathaniel Borenstein (First Virtual employee's): The Simple MIME eXchange Protocol

Mark Twain Bank: Welcome to Mark Twain Bank,

Moeller, Michael: PC WEEK: IB takes charge of E-commerce, PC WEEK April 29, 1996

Netscape: SSL Version 3.0,

NOVA Information Systems: Nova Information Systems WWW Page - Bank Card Processing,

Rescorla, E.; A. Schiffman: draft-ietf-wts-shttp-00, (Note - this is a working draft and subject to change)

Rocket Science Games: Rocket Science Home Page,

Vantage Services, Inc.: Welcome to Vantage Services, Inc.,

Copyright © 1996 by Keith Lamond
Please read copyright notice