An major factor in the evolution of the Web is Electronic Commerce: the ability to buy, sell, and advertise goods and services to customers and consumers. One concern in the development of Electronic Commerce on the Web is the trust that can be placed in the provenance, reliability, security and privacy of information available from or transferred over the internet. Another concern is the need for low friction commerce transactions allowing quality and ease of use for consumers, a key factor the future of Electronic Commerce. The potential for global electronic commerce is immense; much of this potential is and will be realized by the continued development of Web technologies. The World Wide Web Consortium, leading the web to its full potential, is therefore concerned with the evolution of Electronic Commerce on the Web. The role of W3C is to focus on core infrastructure technologies for Electronic Commerce and identify common infrastructure needed in this area. W3C is not committed for example in specifying banking systems nor schemas for specific Electronic Commerce applications.
W3C has closed its Ecommerce and Micropayment Activity, but through the following
activities W3C is committed to key factors for success in the evolution of
Electronic Commerce:
The Electronic Commerce Activity is currently involved in realizing the opportunities in micropayments, and this forms the main thrust of the Activity.
Micropayments are very small payments made over the Web for pages that you access. Micropayments cover transactions which are too small to be economical as credit card transactions, and can be as little as a fraction of a cent. Micropayments provide an alternative to subscription and advertising as a source of revenue. Payments could in principle go in either direction - some sites could conceivably pay you to visit them.
How do micropayments work from the user's point of view? At this stage it is impossible to be specific, but we can at least give some idea. You can imagine something like the following:
If you click on a link requiring a payment, the browser would look for an "electronic wallet", a piece of software that acts a bit like a rechargeable phone card, except that it would work for Web pages rather than phone calls. The wallet would make payment for information downloaded, keeping track of how much was left, how much had been "spent", and so on.
But how would you know what a given piece of information cost? Links you have to pay for might be marked in a different color, and in principle, the browser could show the cost as you moved over the link. Only when you actually clicked on the link would the payment be made, and only then would the information you requested be made available via your browser.
The wallet might come pre-installed as part of the browser. If not, you would be invited to download a new wallet. Before the wallet could be used it would need to be initialized in some way, figuratively filling it with cash or credit. Different micropayment systems will have different approaches.
The starting point is a standard way to represent payment information for following hypertext links from Web pages. The browser can interpret this information to show the cost of each link to the user, and to ask the wallet to make a payment when the user clicks on a link.
The browser communicates with the wallet via an API (Applications Programming Interface). When the user makes a payment via the browser, the browser talks to the wallet, and the wallet initiates the payment. This may involve a third party payment server. Some kind of token, or other form of recognition of payment, is sent to the Web server, and the document, image, or other Web resource, is made available to the user.
A browser could of course have multiple wallets, which would be necessary where several payment systems are in operation. You might be able to access each wallet independently of the browser; for example, to see how much money is left, to refill it or to uninstall it.
What W3C proposes to do is to develop a common markup language for payment information, and an API to support such a system. The API is needed to enable the browser to talk to the wallet; the markup format is needed as a standard way for micropayment information to be encoded.
By defining a non-proprietary format for payment information and the software interface to the wallet, W3C seeks to catalyze the market adoption of micropayments for the Web. By working with the companies that have been implementing micropayment schemes, W3C will be able to leverage their experience.
Payment information will indicate the payment required for following links to particular Web addresses. The information could include the price, the currency, payment scheme, and so on, even how to get a wallet for a particular payment scheme. Some information will be "public" while other information will be "private" to particular payment schemes. A W3C Recommendation for a markup format will allow this information to be encoded in a standard way.
This will provide a standard set of procedures that allow the wallet and the browser to talk to each other. The API will be browser- and payment scheme-neutral, thus allowing for different payment mechanisms to be dropped into place as needed. Users would be able to download new payment schemes without further changes to their browsers.
Micropayment standards were proposed at the Electronic Commerce Interest Group meeting in September 1998. A sub-group met in Paris the following February to discuss this proposal in greater detail. The representation of pricing information is a need common to all payment schemes, be they based on online connections, such as the Micrommerce system from France Télécom, CyberCoin from CyberCash or the original GlobeID scheme, or semi-online such as Millicent (Digital Equipment) or IBM Micro payments, or even stored-value like systems as announced by Mondex or VISA cash.
The activity now has two Working Groups, the Micropayment Markup Working Group and Micropayment API Working Group.
The Common Markup for micropayment per-fee-links was published as a W3C final Working Draft on 25 August 1999. This specification provides an extensible way to embed in a Web page all the information necessary to initialize a micropayment (amounts and currencies, payment systems, etc). This embedding allows different micropayment electronic wallets to coexist in an interoperable manner. Put simply, it makes it easy for merchants to propose multiple payment systems and allows users to have more than one method of payment in operation from their browser.
The architecture of the system envisaged is shown diagrammatically below. The "user agent" is the browser plus software associated with it and working on the user's behalf. The Draft focuses specifically on the flow of information between the Merchant server to Per Fee Link Handler-Browser, and specifies the payment markup information.
The PFLH is a common module, implemented as an applet or plug-in that allows multiple micropayment schemes to share the same basic user interface paradigm and code.
The Last Call Working Draft "Common Markup for micropayment per-fee-links" was held at this stage to await significant implementation experience, allow possibly related work in other Micropayment WGs to progress further, and collect comments on the public mailing list.
Last Call comments are now considered by the Working Group, currently specifying a new draft version to be submitted for Candidate Recommendation.
Last modified $Date: 2001/06/20 08:58:11 $