ERCIM News No.30 - July 1997

Joint Electronic Payment Initiative

by Daniel Dardailler

JEPI, the Joint Electronic Payment Initiative, is a joint project between the World Wide Web Consortium (W3C) and CommerceNet with a number of industry partners (IBM, Microsoft, CyberCash, GCTech, etc) to explore the process that takes place, typically, after shopping and before actual payment begins. This is the point in time where the exact payment instrument (credit card, debit card, electronic check, electronic cash, etc) must be agreed upon between the browsing client and the merchant server, and then the transaction can take place.

With the development of appropriate HTTP extensions like PEP (Protocol Extension Protocol) and UPP (Universal Payment Preamble), JEPI phase 1 offers an automatable payment selection process, which ultimately enhances the user shopping experience while allowing coexistence of multiple payment systems.

The Internet is becoming an increasingly commercial arena in which payments are rendered for goods, information, and services. To support such commerce, various Internet payment protocols have been proposed and adopted by a variety of organisations. Most of these payment protocols are, however, incompatible with each other, and there appears to be little prospect of unification or abandonment of most of these protocols.

In fact, the existence of different payment mechanisms is justified because there are and will always be different needs to be satisfied in terms for instance cryptography, latency of the transaction, amount range, etc.

While the multiplicity of payment systems brings healthy competition among players, it also brings more complexity to the end-users, ie consumers and merchants. The goal of the first phase of the JEPI project is, while allowing multiple payment systems, to assist consumers and merchants in the process of selecting a payment system appropriate for both parties for any given transaction.

Architecture

W3C's position for the JEPI project is to provide an architecturally viable and neutral mechanism for doing the negotiation of payment instruments over the Web in an automatable way. It is not to provide a new payment protocol or a way to convert dynamically between payment schemes.


JEPI architecture

 

Let's put the emphasis on this point: JEPI is not about a new payment protocol nor a conversion framework but rather a way to negotiate and select a single payment system to be used for a particular transaction from the group of multiple payment systems installed on the client and server platform.

JEPI hinges around creating specifications for a pair of negotiation protocols:

Since PEP is not specific to payment, we will only concentrate on UPP in this article.

The UPP Layer

The Universal Payment Preamble (UPP) is the foundation of JEPI. It provides the semantics of the payment selection. It is based on PEP and therefore operates at the HTTP level.

UPP headers allow parties to negotiate payment alternatives at any point in shopping, until a final hand-off to a particular chosen payment system. It provides two capabilities: payment service negotiation and initiation of the specific payment system. The payment service and initiation information are sufficient to smoothly bridge from shopping to payment and, if appropriate, from payment back to other customer - vendor interaction.

The Universal Payment Preamble is so called because it exchanges information that needs to be resolved before a particular payment system is entered and provides an initiation message to enter the payment protocol.

In addition to allowing exchange of purchase information such as amount, currency, brand, etc, UPP also provides a way of transitioning to the next state depending on the result of the execution of the chosen payment system; either side can notify success, failure, or cancel of the transaction.

an example of UPP Flows:

Client -> Server
GET http://www.arix.com/catalog.htm HTTP/1.1

The client request the catalog.

Server -> Client
....
Content-Type: text/html
Protocol-Request: {http://w3.org/UPP {str req} 
{for /SubmitButton}}
Protocol-Info:
{http://CyberCash.com/Coin {for /*}},
{http://GCTech.com/GlobeID {for /*}}
Content-Length: 807
...

The server requests the client to use UPP protocol for the Submit button. The server also informs the client that he can accept Coin and GlobeID.

Client -> Server
POST http://www.arix.com/SubmitButton HTTP/1.1 Protocol:
{http://w3.org/UPP {via http://CyberCash.com/Coin}} 
{http://CyberCash.com/Coin {params {account 12345} 
{expire 9/19/99} {amount {usd 270}}}}

The client presses the Submit button, and tells the server that it is using Coin. He also sends a series of payment information, i.e. the account number, expiration date and the amount. 

Server -> Client
Content-Type: application/cybercash
Protocol: {http://w3.org/UPP
{params {success /worked}
{failure /didnt}
{cancel /incomplete}}}
Content-Length: 359
...

The server executes the chosen payment system, and informs the client about 3 URLs to choose from depending on the result.

As of the writing of this document, we have an implementation of PEP and UPP available as extensions to Microsoft Internet Explorer 3.01 and IBM web server on Windows NT. We have made a demonstration of this setting at the Santa Clara Web Conference in April 1997.

PEP work is now being conducted in the W3C and IETF HTTP working group (where it belongs). We also started internally the discussions about the future of this activity within W3C. A possible JEPI phase 2 could encompass several elements, ranging from revising UPP in the context of the evolution of PEP and extending HTML to address issues arising from micropayment.

W3C is in the process of getting feedback from the industry as to what priority should be given to the items in the above list. More information at http://www.w3.org/pub/WWW/Payments/white-paper.html

Please contact:
Daniel Dardailler - INRIA/W3C
Tel: +33 4 93 65 79 83
E-mail: danield@w3.org

return to the contents page