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:
- a generic HTTP extension framework called PEP allowing a Web client
and server to ask one another what extension modules they support, negotiate
parameters for these extensions, etc
- a specific extension module, UPP, used to negotiate over the payment
instrument (check, credit card, debit card, electronic cash, etc), brand
(Visa, MasterCard, American Express, etc), and payment protocol (SET, CyberCash,
GlobeID, etc).
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
