Credits and Debits on the Internet

Since the advent of banking in the Middle Ages, bank customers have used paper-based instruments to move money between accounts. In the past 25 years, electronic messages moving through private networks have replaced paper for most of the value exchanged among banks each day. With the arrival of the Internet as a mass market data network, new technologies and business models are being developed to facilitate electronic credit and debit transfers by ordinary consumers.

These new systems include CyberCash (which is a gateway between the Internet and the authorization networks of the major credit cards) and the Secure Electronic Transactions protocol (a standard for presenting credit card transactions on the Internet), as well as First Virtual (a way of using e-mail to secure approval for credit card purchases of information), GC Tech (a payment system that can use credit or debit via an intermediation server), and NetBill (a public­private-key encryption system for purchasing information).

Conventional checking

In today's banking world, money consists of ledger entries on the books of banks or other financial institutions. A checking account, also known as a demand deposit account (DDA), records deposits by the consumer and can be used, via the consumer's instructions in the form of a check, to make payments to third parties. Typically, a check is written by a consumer, authenticated by signature, and presented to a merchant, who may endorse it with a signature before presenting it to a bank for payment. If the merchant's bank and the consumer's bank are the same, it can simply transfer the funds on its ledgers from the consumer's account to the merchant's. If the payer and the payee keep accounts at different banks, the payee bank presents the check for settlement to the payer's bank and receives the funds in return through a settlement system. Several private check clearinghouse systems, as well as the Federal Reserve system, provide settlement services in the United States [Fig. 1].

When checks are sent to banks for deposit, merchants do not yet know if consumers have adequate funds and therefore need to find out whether the checks cleared. Similarly, consumers receive statements from their banks showing which checks have been paid. Any discrepancy between bank records and those of the payers may indicate that forged checks were presented against consumers' accounts.

This model works equally well when there is a negative balance in consumers' accounts, at least if the consumers' banks are willing to extend credit--that is, to lend the consumers funds needed to pay off the checks. Many banks in the United States and Europe provide such credit facilities, sometimes referred to as "overdraft protection." A credit card is another example of an account that lends money to the consumer.

The simple model below illustrates the major issues that must be addressed in designing an electronic credit or debit system.

• Naming: there must be an unambiguous way of identifying the payers' bank accounts and the payees' bank accounts.
• Signatures: it must be possible for the payers' banks to verify that payment instructions were generated by people authorized to use accounts.
• Integrity: electronic checks should be difficult to alter.
• Confirmation: payees must have confirmation that transfers took place; payers must have notification of transfers out of their accounts.
• Confidentiality: third parties should not be able to monitor such payments.
• Settlement: separate banking institutions must have a way of settling their accounts.

Such a system does exist for paper checks. In the United States and Canada, a bank identification code and account numbers are encoded in magnetic ink on the check. But the naming of accounts is not standardized internationally. Payees provide their account numbers when endorsing checks. The payers' banks match the signatures on checks with customers' signatures on file at banks. Integrity is ensured by the use of special paper and the practice of writing checks in ink with no alterations. The U.S. Federal Reserve system provides a vehicle for settlement, and confirmation takes the form of periodic statements or special notices for bounced checks. If checks are presented in person or mailed in sealed envelopes, they are generally protected from observation by third parties.

From a business perspective, payment systems differ in the warranties the different parties make and in the liabilities they assume. For example, the payers' banks are responsible for verifying signatures on checks. If this fails to happen, the payers are not liable for forged checks drawn on their accounts. It is possible to cut the cost of the entire process if payment messages can be readily tied to the parties' accounting systems--for instance, by including purchase order numbers or a consumer's account number with a merchant on all checks. It may also be desirable to link payment to some proof that merchandise has been delivered. These links to other processes are among the principal benefits of electronic payments.

In a payment processing system, the cost of normal operations is frequently outweighed by the costs associated with exception handling. If a typical transaction costs US 5 cents to process, and the manual labor associated with handling errors and exceptions comes to an average of $25, even with an error rate of only two per thousand, exception costs will equal normal processing costs. As electronic processing drives down the cost of normal transactions, exception handling becomes relatively more significant. Payment systems must therefore be implemented to the highest standards of reliability, with automated procedures for recovering from errors whenever possible.

[2] In this model of credit card transactions, consumers present their cards to the merchants who submit the card numbers and transaction details to the authorization system, which either approves transactions directly or routes the requests to the card issuing bank for approval. Periodically--for example, at the end of the day--merchants submit details on approved transactions to their banks. This information is submitted to the card association for settlement after a bank nets out transactions for which it serves as both card issuer and acquirer.

The case of credit cards

The credit card system was designed to provide immediate gratification of the wants of consumers by allowing them to purchase goods or services on credit. A credit card is a token of trust that transfers the risk of granting credit from a merchant to the card-issuing bank. Once a merchant has had a purchase authorized by the card issuer over the private authorization network, the merchant is assured of payment and the card issuer assumes responsibility for billing the consumer and collecting the money. Settlement takes place later, when the merchant periodically submits a batch of authorized transactions to the merchant's (acquiring) bank for settlement with the card issuer. But the issuer's assumption of risk is limited, however, to "card-present" transactions, such as those taking place in retail stores. When a merchant accepts a credit card by mail or phone ("card not present"), the card issuer accepts only the risk of nonpayment; the merchant bears the risk of fraudulent card usage. Merchants pay the costs of credit card use because selling on credit expands their business. Under U.S. law, a consumer's liability if someone else fraudulently uses the consumer's card is limited to $50 [Fig. 2].

In a card-present transaction, the merchant validates the payer's signature by matching the one on the back of the card against the one on the charge slip. Integrity is protected by the device of giving the consumer a carbon copy of the slip. The consumer's account number is verified by the embossed number on the credit card. Settlement is handled by card associations (such as Visa and MasterCard). The merchant receives immediate confirmation of a transaction while submitting it for authorization by way of the card association's private data network.

When a catalog sale takes place by mail or phone, the merchant has no way of verifying the consumer's right to use the card number proffered. At best, the merchant can request the consumer's billing address and receive an address verification. In effect, a credit card purchase requires only that the card number be conveyed from buyer to seller. For this reason, consumers are asked to protect their credit card numbers.

While conventional checking and credit card systems may seem quite similar, the legal meaning of credit card and check payment differ significantly. Credit card companies warrant their merchants; a person can challenge a credit card charge if dissatisfied with the goods. Checks provide no such recourse. If a person buys a plane ticket on an airline with a check, and the airline goes bankrupt before the ticket can be used, the unlucky purchaser becomes an unsecured creditor, behind many other claimants. By contrast, someone who pays for a ticket with a credit card may claim restitution from the card-issuing bank, and the card issuer in turn is entitled to redress from the airline's bank, which must stand behind the airline.

Payment systems vary significantly in their allocation of liability and in the warranties made by the different parties. Technical mechanisms have a strong influence on the willingness of parties to assume liability. If only the payer's bank can verify a signature on a check, the merchant or payee bank will not assume any liability for fraudulent signatures. But if public-key­based "signatures" make it possible for a merchant to verify them on an electronic check, merchants can be expected to undertake verification as they now do in card-present transactions.

Transactions on the Internet

Translating checks or credit card transactions to the Internet requires finding electronic and business model equivalents for the functions described above.

Signatures and confidentiality are the two biggest problems in creating digital payment instruments. These issues are typically handled with some form of cryptography. The use of public­private-key pairs allows a message to be "signed" digitally and verified by anyone who has the public key. Some form of public-key infrastructure, such as certificates, must be employed to associate a named user or an account unambiguously with a particular public key. Message digests provide integrity.

Most payment systems require special consumer and merchant software to prepare and process electronic payment messages. Although the consumer software is often described as an "electronic wallet," that term is misleading; funds are never kept in the wallet, which acts rather as an electronic checkbook for signing payment orders--managing keys, performing cryptographic operations, and formatting messages, as well as acting as a check register for keeping track of transactions.

The use of credit cards over the phone for catalog shopping is well established. Some of the first Internet systems propose to extend that model to shopping from Web-based catalogs.

[3] CyberCash Inc., Reston, Va., provides consumer software, merchant software, and a gateway to support the secure communication of credit card transactions over the Internet.

CyberCash's gateway

CyberCash Inc., Reston, Va., implemented a system for protecting credit card presentation on the Internet in April 1995. The system was one of the first of its kind. The company, which provides software to both consumers and merchants, operates a gateway between the Internet and the authorization networks of the major credit card brands. As Nathaniel Borenstein, chief technical officer for First Virtual Holdings Inc., San Diego, Calif., noted, "Debugging obscure problems with incompatible implementations of Internet protocols is not a core competence of most financial institutions"--hence, the role for a gateway service.

The consumer begins by downloading the wallet software, which supports encryption and transaction record keeping. Like a physical wallet that may hold a number of credit cards, the software wallet can be used by the consumer to register several credit cards. Another software package provides similar services to the merchant. Messages are encrypted using a random symmetric key, which in turn is included in the message encrypted under the recipient's public key. The CyberCash public key is built into the wallet and merchant software. Consumers generate a public­private-key pair when they register credit cards with the wallet software, and the public key is sent to CyberCash, where it is maintained in a database. While consumers, merchants, and CyberCash all have public­private-key pairs, only CyberCash knows for certain everyone's public key. As a result, the company can exchange information securely with consumers or merchants, but they communicate with one another in the clear, relying on CyberCash to authenticate all signatures [Fig. 3].

When the time comes to make a purchase, the consumer requests the item desired by selecting it with a Web browser. The merchant's server sends the wallet software a cleartext, signed payment-request message that describes the purchase and indicates which credit cards the merchant accepts. The wallet software thereupon displays a window that lets the consumer select which credit card to use, and approve the purchase and the amount.

A credit card payment message, including a signed and encrypted description of the transaction, along with the consumer's credit card number, is sent back to the merchant, which forwards the payment message, along with the merchant's own signed and encrypted description of the transaction, to the CyberCash gateway. There, CyberCash decrypts and compares the two messages and their signatures. If they match, it submits a conventional authorization request and returns the charge response to the merchant, whose software confirms the purchase to the consumer's wallet software (credit card response). Additional messages cover refunds, voiding transactions, capture, and status inquiries.

CyberCash operates its gateway as an agent of the merchant's (acquiring) bank. Thus it must be trusted to decrypt the information for resending over conventional authorization networks.

Since the information is encrypted under CyberCash's public key, the merchant does not actually see the consumer's credit card number--a procedure that in theory cuts the risk that customer credit card numbers will be abused. In practice, so many catalog companies organize their customer marketing records by credit card numbers that an acquirer usually authorizes CyberCash to provide them to merchants on request.

[4] The operation of the Secure Electronic Transaction (SET) protocol relies on a sequence of messages. In the first two, the consumer and merchant signal their intention to do business and then exchange certificates and establish a transaction ID number. In the third step, the consumer purchase request contains a signed hash of the goods and services order, which is negotiated outside the protocol. This request is accompanied by the consumer's credit card information, encrypted so that only the merchant's acquiring bank can read it. At this point, the merchant can acknowledge the order to the customer, seeking authorization later (steps five and six) or perform steps five and six first and confirm authorization in step four. Steps seven and eight give the consumer a query capability, while the merchant uses steps nine and ten to submit authorizations for capture and settlement.

Secure electronic transactions

In February 1996, Visa and MasterCard announced their joint support of a standard protocol, dubbed Secure Electronic Transactions (SET), for presenting credit card transactions on the Internet. SET is designed to operate both in real time, as on the World Wide Web, and in a store-and-forward environment, such as e-mail. As an open standard, it is also designed to permit consumer, merchant, and banking software companies to develop software for their respective clienteles independently and to have them interoperate successfully.

In the CyberCash protocol, only CyberCash knows everyone's public key. SET, however, assumes the existence of a hierarchy of certificate authorities that vouch for the binding between a user and a public key. Consumers, merchants, and acquirers must exchange certificates before a party can know what public key to employ to encrypt a message for a particular correspondent [Fig. 4].

Although the software industry is moving rapidly to implement SET, the protocol poses significant problems for banks. Card issuers must invest considerable sums to have public key pairs and certificates issued to their card holders. Yet the benefits to the SET card issuers are not clear. A standard protocol may reduce software costs to merchants and consumers, as well as inhibit merchant fraud, but the cost of such dishonesty is borne by the acquirers, not the card issuers. What is more, it is not clear that SET will generate significant new credit card volume, as opposed to merely displacing mail and telephone orders. The card associations suggest that SET transactions, like card-present ones, should involve lower payments to card issuers. Thus a shift from telephone orders to SET could actually reduce the revenues of card issuers, while increasing costs by requiring them to issue certificates. Aligning benefits with costs will require a reallocation of the merchant discount between issuers and acquirers, a politically difficult task for card associations.

First Virtual: no hide and seek

First Virtual provides a mechanism that lets information providers accept credit cards for Internet purchases without resorting to cryptography. Consumers establish account IDs with First Virtual and fax or telephone their credit card numbers to it. To buy information, consumers present those account IDs to merchants, who then connect to the First Virtual server to verify that IDs are valid; if so, the information is sent directly to the consumers. The server then sends them an e-mail message asking if they are willing to pay for the information. Consumers e-mail a reply indicating "yes," "no," or "fraud." If the answer is yes, First Virtual submits the user's credit card number through its acquirer, and the consumer's card is charged. After holding the funds for 90 days, the company transfers them to the merchant by means of an automated clearing house.

The First Virtual model has several key premises. First, consumers do not really know if they want a piece of information until they have looked at it. Second, the cost of sending information electronically "on approval" is negligible, so a merchant has lost very little if a consumer's answer is "no." Third, most consumers are honest: they will not systematically order goods and then answer "no" even when they are satisfied. (As an added deterrent to dishonest behavior, First Virtual will cancel a consumer's account if the pattern of usage suggests abuse.) By not charging consumers until they are satisfied, the system eliminates the cost of reversing charges for information that was not delivered as a result of network or computer problems.

Since the request for payment approval comes by e-mail, while goods are typically delivered over the Web, First Virtual believes that its model is so hard for an attacker to abuse that the risks are justified. Moreover, because the company delays payment to merchants for 90 days, consumers have plenty of time to discover fraudulent charges on their credit card statements, in which case First Virtual can easily reimburse the credit card with the funds it is holding.

In the First Virtual model, naming is provided by the account ID. In lieu of signatures, the company relies on the integrity of the Internet's e-mail infrastructure to ensure that a real consumer is answering yes or no. There is no message confidentiality, except that the account IDs may be viewed as pseudonyms. Confirmation is provided by e-mail and credit card statements. Settlement is handled first by the credit-card provider transferring payment to First Virtual and then First Virtual transferring payment to the merchants.

The company has been in operation since October 1994. It claims more than 180 000 consumer accounts.

[5] In the electronic check concept developed by Financial Services Technology Consortium Inc., consumers uses smartcards or secure processors to compose and sign electronic checks. A check is sent, together with the consumers' public-key certificates and transaction details, to the payee for endorsement. The payee then adds its own signature and certificates and sends the check to its bank for deposit. The results of transactions are reported to both merchants and consumers. Click on image to enlarge.

Electronic checks

Beginning in the early 1970s, banks began searching for ways to reduce the costs of check processing (6.5¢­13¢ per item) by handling payments electronically. In direct payroll deposit, an employer sends a list of payroll payments to its bank, which then transfers funds to the employees' accounts at their banks through one of several automated clearinghouses (ACH). Consumers use direct payment to deal with recurring bills, such as utility, mortgage, and auto loan payments. In 1995, four ACH operators--the Federal Reserve, the New York Clearinghouse, the Arizona Clearinghouse, and VisaNet ACH Services--handled 2.9 billion transactions worth $13 trillion on their private electronic networks. The cost to banks was only half of what they would have spent processing checks manually. Payers and payees saved even more.

For both direct payroll deposit (used today by more than 45 percent of the U.S. workforce) and for direct payments, transactions begin when a large organization sends a batch file or tape to its bank with a list of payments or requests for payment. Because this is a batch system, it can take as many as three days for a payee to receive confirmation that a payment has cleared. The existence of these ACH systems for settlement between banks provides a strong base on which to build consumer-oriented electronic payment systems that can accept individual electronic requests for payment originating with consumers.

On the Internet, a paper check can readily be replaced by a digitally signed message--that is, an electronic check. A consortium of banks working through the Financial Services Technology Consortium (FSTC) Inc. has demonstrated a prototype electronic check system that maps directly into the model described above for conventional checks. The payer uses a secure processor, in the form of a PC card, to generate a digitally signed payment instruction, or "check," that is transmitted to the premises of the merchant where it is "endorsed" digitally before it is sent on to the merchant's bank. There, the check can be settled through an existing ACH [Fig. 5]. Other scenarios are also supported; for example, payers can send electronic checks to their own banks, which would then transfer funds directly to the payees' banks.

Standards for conveying invoice and remittance information so that payments can be readily linked into accounts payable and accounts receivable processing systems are an important component of the electronic check concept.

The FSTC model assumes that public keys and certificates are widely available, with banks vouching for their customers and associations of banks, such as an ACH, vouching for one another. The insistence on a hardware token for protecting a private key is designed to provide a high level of protection against such threats as Trojan horse software.

Instant debit systems

To the extent that FSTC's electronic checks rely on the conventional ACH system for clearing, they cannot give the merchant immediate payment confirmation of the sort provided by credit card authorization. CyberCash, Carnegie Mellon University, and GC Tech have introduced, or are developing, low-cost debit payment systems that give a merchant an immediate assurance that the payment will go through.

These systems provide a service model based on the concept of an on-line bank account, with immediate posting of transactions so that payees can get real-time confirmation that funds are available. In addition, they offer an interface to existing electronic funds-transfer mechanisms, including both ACHs and credit cards, so that consumers can easily transfer funds between their primary banks or credit accounts and their Internet payment accounts. Furthermore, these systems aggregate many on-line transactions for batch settlement over traditional settlement networks. They differ in the order of steps required for a transaction, in the consumer protection they provide in the event that goods are not delivered, and in the balance they strike between computationally expensive public-key cryptography and the use of shared-key cryptography.

GC Tech's turnkey offering

GC Tech SA, headquartered in Paris, France, bases its business model on turnkey payment systems software for banks and other financial institutions [Fig. 6]. The intermediation server in the GC Tech model maintains a "ledger" of consumer funds on account in the payment system. These funds may actually be on deposit at the consumer's bank, but their disposition is accounted for on the intermediation server's books. Account funding may take the form of a charge against the consumer's credit card or a transfer from the consumer's checking account to the payment system account. A consumer opens an account by downloading the wallet software and specifying a credit card used to fund the account.

When the consumer has selected a product for purchase, the merchant responds with a digitally signed payment-request message that is sent to the consumer's electronic wallet, which verifies the terms of the transaction and forwards the message to the intermediation server. The server then issues an authentication challenge to the consumer's wallet software. Upon receiving a correct response, the server debits the consumer's account and credits the merchant. Accumulated merchant credits will be settled in a single periodic batch transaction. If the consumer has sufficient funds, the server returns a digitally signed proof of payment (PPT) to the consumer's wallet software, which forwards it to the merchant. Assured of payment, the merchant can now deliver the goods.

The GC Tech cryptographic model assumes that the intermediation server and the merchant have public­private-key pairs, while consumers have only a PIN number. When the consumer forwards the proof of payment to the server, it proposes a session key encrypted under the server's public one. This session key is used to encrypt the authentication challenge and response, as well as to protect the PIN from disclosure. The proof of payment, signed by the server's private key, can be independently verified by both consumers and merchants. This model eliminates the need to issue and manage certificates for consumers.

Various entities are expected to use the GC Tech system, marketed under the brand name GlobeID. The GlobeID operator in France is Kleline SA, a joint venture operated by Moet Hennessey Luis Vuitton SA and Compagnie Bancaire SA, all three of which are in Paris. U.S. operations are expected to start in early 1997.

[7] The NetBill payment protocol has eight steps. In the first, the consumer and merchant authenticate each other using their public-key certificates and establish a symmetric session key to protect the privacy of subsequent messages. The first message requests a quote based on the consumer's identity, to allow for customized per-user pricing, such as volume discounts or support for subscriptions. If the quote (step two) is accepted (step three), the merchant sends the digital information to the consumer (step four) but encrypts it and withholds the key. The consumer software constructs an electronic payment order (EPO) describing the transaction and including a cryptographic checksum of the goods received. The order is signed with the consumer's private key and sent to the merchant, who verifies all its contents, appends the key for decrypting the goods, endorses the EPO with a digital signature, and sends it on to the NetBill server. The NetBill server verifies funds in the consumer's NetBill account, debiting the consumer and crediting the merchant, and a digitally signed receipt, including the key to decrypt the goods, is sent first to the merchant and then on to the consumer. The consumer software can now decrypt the purchased information and present it to the consumer.

NetBill for information delivery

NetBill, a system under development at Carnegie Mellon University (CMU), Pittsburgh, in cooperation with Mellon Bank Corp., also in Pittsburgh, is optimized for delivering such information goods as text, images, and software over the Internet. Its developers, who include the author, have stressed the importance of guaranteeing that consumers receive the information they pay for. To that end, consumers are not charged until the information has actually been delivered to them. Similarly, merchants are guaranteed payment for goods delivered. The basic NetBill protocol has eight steps, beginning with the authentication of identity (using public-key cryptography) and ending with the transmission of a decryption key to the consumer so that the information being purchased can be decrypted and presented [Fig. 7].

In this system, consumers are not charged until the (encrypted) goods reach them. At the same time, if there is not enough money in the consumer's account, the transaction will be rejected and the key never delivered, preventing the consumer from using information that has not been paid for. The merchant's endorsement of the electronic payment order also serves as a warranty that what was received by the consumer is what the merchant intended to deliver. In the unlikely event that the merchant or client machine goes down after the consumer has been charged but before the key is delivered, the consumer can request a copy of the receipt--which contains the key--from the NetBill server.

Note the contrast in message flows between the GC Tech and NetBill systems. GC Tech requires merchants to communicate with the intermediary by way of the consumer's software. In a NetBill microtransaction, only the merchant talks directly to the accounting server.

NetBill will fund its accounts by charging the credit cards of consumers to put spending money in their NetBill accounts. These funds will be held at NetBill's bank. As merchants accumulate credit balances, funds will be transferred via VisaNet to the merchants' banks.

CMU and Mellon Bank expect to launch a commercial trial of the NetBill system in the first half of 1997. Transaction fees, paid by the merchant, are expected to range from 2.5 cents on a 10 cent transaction to 7 cents on a $1 transaction. CyberCoin for small deals

In September 1996, CyberCash Inc., Reston, Va., introduced its CyberCoin service, which is designed to support low-cost (25 cent to $10) transactions for information goods over the World Wide Web. Like the NetBill and GC Tech systems, this one relies on a real-time account database to track Internet transactions. The CyberCash business model assumes that many banks will want to offer a bank-branded payment service that CyberCash would operate on their behalf. This approach would be similar to the recent trend in credit cards: fewer than 25 percent of banks do their own processing; most of them leave it to specialized companies such as First Data Corp., Atlanta. Ga.

A CyberCoin account can be "loaded" either by a charge to a credit card or by a transfer from the consumer's checking account. In the latter case, the transfer is handled in one of several ways: as an ACH transaction, by direct access through a debit or ATM network, or by other means. Depending on the mode of access and the user's level of authorization, funds may become available immediately or held for as many as three days until the transaction clears. While it is less costly to the intermediary to obtain the funds through the clearing house--thus avoiding the credit card discount fee--consumers are likely to prefer credit cards that give them instant access to the funds and 30 days before they have to pay the bill.

In the CyberCoin system, like the NetBill one, merchants deliver the goods encrypted and provide the key only after payment is confirmed. But rather than using RSA digital signatures on every small transaction, the CyberCoin system uses asymmetric cryptography only to load accounts and establish a session key. Individual transactions are then signed with this symmetric key, thus reducing the data processing burden.

CyberCash has established partnerships with a number of important players. Netscape, for one, has agreed to bundle the CyberCash wallet software with its browser software products.

The future is not like the past

Payment systems can be expected to go on proliferating for the next several years, until the market determines the most desirable combinations of functions, price, and performance. The paper world, after all, has many different instruments, which embody different tradeoffs among risk, cost, complexity, responsiveness, and the time until the transaction is final. The same variety should be expected in electronic credit and debit systems.

Yet new technologies uncover new ways to distribute risk, liability, and cost among the parties to a transaction, so that new financial instruments with no comparable paper analog.are also to be expected. They will take somewhat longer to develop, however, as they require changes in regulatory assumptions, case law, and participant behavior, all of which evolve much more slowly than technology does.