Roger Clarke's Web-Site

 

© Xamax Consultancy Pty Ltd,  1995-2016


Roger Clarke's 'Net-Based Payment Schemes'

Net-Based Payment Schemes

Roger Clarke

Version of 1 December 1996

© Xamax Consultancy Pty Ltd, 1995-96

This document is at http://www.rogerclarke.com/EC/EPMEPM.html


Scope

This document is concerned with a particular class of payment mechanisms, viz. those that support circumstances in which the payer is *not* present at the point of sale or service, but does have electronic communications facilities available, e.g. is connected to the Internet, or to some other manifestation of the emergent global information infrastructure, such as a cable-TV installation with enhanced capabilities.

(I use the term 'electronic payment schemes' more generally, to cover not only net-based, but also card-based schemes, including credit-cards, debit-cards and stored-value cards, and EFT/POS and FEDI).


Contents


Classes of Schemes

Payment mechanisms can be classified in a variety of different ways.

A good start is to delve into the history of money.

Goldschlager & Harper (1996) provide an analysis according to the nature of the monetary system underlying the payment scheme:

Goldschlager & Harper see considerable scope for a Pure Credit system on the Internet, because such a scheme is capable of operating internationally, and it enables direct transfer of funds between any pair of seller and buyer, rather than being restricted to institutionalised sellers, as schemes like credit-cards tend to be.

A useful classification of the kinds of schemes for electronic cash is as follows:

Because of the richness of choice, both between classes of mechanism and of particular services within each class, the need has arisen for a means whereby payer and payee can agree on which mechanism to use:

In addition, since it seems inevitable and desirable that more than one financial institution, and/or more than one scheme, will be involved in payments, a mechanism will be needed for clearing payments. That seems likely to come about pretty quickly. See, for example:

Finally, there are some other schemes whose names have bobbed up from time to time, but which I know little about, or have failed to investigate so far.


Evolutionary Approach: Credit-Card Details
(1) Send Credit-Card Details by Email

It is entirely feasible for the payer to send credit-card details 'in clear' to the payee, by unencrypted email. This risks interception along transmission lines and in nodes along the way. Assessments of the degree risk of risk involved vary from a lot more than conventional mechanisms like telephone calls and handing over your credit-card in a restaurant, to a lot less. In Australia, and some other civilised countries, consumers are substantially protected against fraud arising in such circumstances, and the financial institution and/or merchant carry the risk.

(2) Send Credit-Card Details by Separate Dial-Up Connection

A minimalist approach to protecting the credit-card details is to require a separate dial-up connection from the payer to a card-validating intermediary. This seems unlikely to provide a satisfactory level of convenience to the payer, but at least one such service exists.

(3) Pre-Record the Card Details

More ambitious schemes involve the payer pre-recording their card number with an intermediary. When they want to effect a purchase, the payer sends a message authorising payment against the card. The intermediary uses a conventional mechanism (e.g. an EFTS, EFT/POS or on-line authorisation network of some kind) to gain the card company's approval.

Such schemes are designed to work variously with credit-cards, with ATM cards, and with debit-cards.

The message can be sent directly from the payer to the payee, who then sends a message to the intermediary; or the payee may send the message to the intermediary, who then sends a confirmatory message to the payee.

(4) Send Credit-Card Details by Encrypted Transmission

(a) Use Email

Another approach is to place credit-card details inside a message, and encrypt the message, or at least the risk-prone credit-card details. Symmetric (secret key) encryption schemes appear impractical because of problems with key management, but asymmetric (public key) schemes lend themselves to this use: the payer needs software that will encrypt the data using the payee's public key, and the payee can decrypt it using their own private key.

PGP is the mainstream product which delivers this capability. Unfortunately, however, the FBI's atrocious treatment of its originator, Phil Zimmerman, has resulted in long delays in PGP becoming available in a convenient, readily commercialised form. The formation of a company, PGP Inc., to exploit the product, may result in the availability of convenient interfaces for consumers in the near future.

(b) Use Secure HTTP

The Hypertext Transport Protocol (HTTP) provides a means of encrypting transmissions, referred to as Secure HTTP. A transmission using SHHTP is recognisable at browser-level through the use of the identifier 'shttp://' at the commencement of the URL.

This can be used to capture credit-card details using a web-form, and submit them across the Internet in a relatively transmission-secure manner.

(c) Use the Emergent SET Standard

Secure HTTP can offer a secure channel, but does not address authentication and non-repudiation risks.

During 1994-95, MasterCard worked on a proposal called SEPP (which IBM claims was based on their iKP, and which also involved Netscape, CyberCash and GTE), and Visa worked with Microsoft on a proposal called STT. It appears that the web-documents describing those proposals may have been withdrawn (although there may still be an archived copy of STT materials on W3's server).

In early 1996, MasterCard and Visa got back together again, and cooperatively developed a new design drawing on features of both SEPP and STT, and called Secure Electronic Transactions (SET). It is described as an "open, vendor-neutral, non-proprietary, license-free specification for securing on-line transactions". An overview is provided at http://www.rogerclarke.com/EC/SETOview.html.

Appropriately enough, the documentation is available from both Visa and MasterCard, in Adobe Acrobat (PDF) format, for review and comment by all interested parties. A specialised mailing list exists.


Evolutionary Approach: Debit-Card Details

Debit-card transactions involve an immediate charge to the bank account of the card-holder, rather than to a so-called 'revolving credit' account run by a 'credit-card company'. In Australia, debit-card transactions are not permitted unless they are supported by the keying of the PIN. (Some countries have less strong security requirements and consumer protections ...).

If crypto-based techniques like SHHTP and SET are successful in establishing highly secure electronic payment mechanisms, they would be at least as secure as PIN-based transactions, and hence they could be used to support debit-card as well as credit-card transactions.

[Such a development might lead to the widespread use of debit to replace credit, and subsequently the collapse of the market-share of credit-cards. The major payment processing corporations may or may not like that idea, and hence a new battleground may be emerging. But that's another story ...].


Revolutionary Approach: Value-Token Creation and Passing

These schemes involve the payer downloading virtual notes or coins (more generally, 'value-tokens') from their electronic banker and holding them in a virtual wallet on their own hard-disk (workstation, laptop, PDA, etc.).

To make a payment, the payer mails one or more value-tokens to the recipient. The recipient deposits them with the same electronic banker. They may hold the value-tokens, or deposit them in a conventional bank account with that banker, or request transfer of the value to their account with another financial institution.

No doubt clearing systems will be established in due course to enable banks that support various kinds of tokens to settle with one another, and transfer credits (much like clearing systems arose for international currencies and for cheques, etc.).

There are many risks to be managed in this kind of scheme, such as the spender spending the tokens twice, the recipient inventing (forging, counterfeiting) tokens, the bank failing to honour its tokens, and the payer's or payee's hard-disk crashing. Several organisations claim to have crypto-based features that address these risks.

Some of these schemes offer fixed-denomination value-tokens. This can result in additional traffic to break the token into one for the amount to be transferred to the payee, and another to be returned as 'change' to the payer. It may also result in other awkwardnesses (and in particular fragmentation of the value in one's wallet) that need to be managed. Other schemes provide automated adaptation of the values of each token.

To date, the schemes that have been devised feature single-use tokens: it appears that no-one has come up with a multiple-use token yet. This may seem a deficiency in comparison with physical cash, but it may prove to be an entirely adequate way to transfer value in the context of the net.

The big player, at least in intellectual terms, is David Chaum's Digicash, which operates out of Amsterdam. This supports payer anonymity, whereas other schemes that have been implemented or described involve identification of both the payer and payee. The other particularly important product is Cliff Neumann's NetCash, which originated at USC in Marina Del Ray.

Here's a critique of Digicash and NetCash, followed by a proposal for PayMe, a protocol which seeks to combine the best of both ;


Micropayment Schemes

A special sub-set of, at this stage, conceptual or experimental projects addresses the need for a highly inexpensive scheme that will economically support very small payments of cents or even fractions of a cent. The most apparent application of such 'micropayment' systems would be pay-per-view for web-documents.


Revolutionary Approach: Electronic Payment Instructions

These kinds of schemes enable a payer to send a payee an electronic document that contains the equivalent data to that contained on a cheque, i.e. the name of the payer, their financial institution, their account-number with that institution, the name of the payee and the amount to be transferred.

Such a document is of course readily forgeable, and security features are needed, in particular crypto-based user authentication. Some schemes are dependent on a user authentication mechanism such as smart-cards in the payer's and payee's hands, and smart-card reader at each workstation.

A clearing mechanism is needed, so that the financial institutions which provide banking services to the payer and payee can electronically exchange the payment instructions, and settle them.

Some schemes are designed to include verification of the signature by the bank, and others seek to reduce the costs involved by verifying the signature using software running in the payee's machine.

RUNNING SYSTEMS

RESEARCH AND PROPOSALS


Integrated Approach: Stored-Value Card Payment

Schemes of this kind are designed to leverage off what are expected to soon be a well-established payment mechanism.

They require the payer and payee to each insert a stored-value card in an SVC-reader attached to their workstations. The transaction can then be conducted using much the same protocols that are already established for SVC operation at a point of sale, but with the interactions transmitted over the net rather than within the terminal.

As the lines of development being pursued by the Visa Cash and MasterCard Cash products become clearer, it is to be expected that they will migrate in this direction.


Negotiation of the Payment Mechanism (JEPI)

The preceding sections have identified many different ways in which transfers of funds are likely to be effected over the net. Within many of these classes there are multiple competing proprietary standards; and within many of the classes and standards there are alternative service-providers. Payers and payees are likely to use several of them, and each payer-payee pair will need to negotiate which one to use to effect a transaction.

It appears at this stage that the dominant scheme whereby web-browsers and web-servers, representing payers and payees, can conduct a negotiation, will be that devised by the World Wide Web Consortium ( W3C), called the Joint Electronic Payments Initiative (JEPI).

JEPI enables the payer-payee pair to determine which payment mechanism to use, what protocol and what transport. JEPI consists of two parts:

For more information on JEPI, see http://www.w3.org/pub/WWW/Payments.


Schemes Awaiting Analysis and Classification


Unclassified, and Documentation Not Yet Found


Some Sources

There's a great deal of valuable material available. I've drawn on it at various points in the past, and again during the current revision. The sites are loosely classified. They change spasmodically, and they come and go. I do what I can to keep it up-to-date. Suffice it to say that I believe this to be the most comprehensive, highest value-added list currently available.










xamaxsmall.gif missing
The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 50 million in early 2015.

Sponsored by Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer
Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 15 February 1995 - Last Amended: 1 December 1996 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/EPMEPM.html
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2013   -    Privacy Policy