Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
The Joint Electronics Payment Initiative aims to bring key industry players together to assure that multiple payment protocols can operate effectively in Web applications. The concrete goal is automatable payment selection over HTTP.
The first step towards this was Don Eastlake's development of the Universal Payment Preamble, which is also available as an internet-draft (draft-eastlake-universal-payment). The second is the development of an HTTP Extension Protocol to embed UPP in HTTP. The latter proposal is part of the chartered activities of the IETF HTTP WG (draft-ietf-http-pep-03).
This document describes how to use UPP over PEP to support payment selection between clients and merchants. It explains basic operations: requesting available payment choices, presenting multiple choices, demanding a selection, making a selection, and accepting and rejecting choices.
Amongst other things, UPP provides a uniform vocabulary for naming options common to many payment systems, and a uniform syntax for each such option. It is not clear at the current time what mechanism should be used to allow independent payment system designers to name options so that they will not collide with the UPP namespace of shared options. We will use sub-bags to separate the name spaces. That is, we will assume that a bag of the form {upp {upp-parameter-name upp-parameter-value} ... } will be used to hold these parameters. A complete list of these common parameters and their syntax is available in the UPP specification.
In a complete implementation of UPP using PEP, it would be possible to specify these common parameters in the PEP-specified header fields Protocol:, Protocol-Request:, Protocol-Query:, and Protocol-Info: as well as in any payment-system specific headers. In the JEPI demonstration, however, we will not be using these parameters for the generic UPP protocol (they may be used in payment-specific protocols). In this document we will indicate where they are syntactically permitted by using the notation "upp-params." For the demonstration, these will always be omitted in the examples shown here.
For clarity, we omit all of the HTTP headers and message body with the exception of those parts directly related to the operation being demonstrated. The protocol-name URLs shown here are purely for example, and will be determined by the participants at a later date. The URLs for the various for lists will be determined by each merchant application. Because we do not expect proxy servers to participate in the payment negotiation shown during the JEPI demo, the scope parameters of all PEP headers have been omitted: they are defined to default to {scope origin} as required for the demonstration. Similarly, the strength of PEP directives defaults to optional ({str opt}), so it is only shown otherwise.
Either end (client or server) should be able to ask the other what forms of payment it supports.
In order for the client to ask the server what payment choices are available, the Protocol-Query: header is added to an HTTP request from the client to the server. JEPI implementors: In the demo, only the server will generate these requests.
GET URL
Protocol-Query: {http://www.w3.org/UPP upp-params}
This means "do you have UPP available at the URL specified in the HTTP request that contains this header." If any of the upp-params are specified then they further restrict the meaning of the query (i.e. if a {upp {amount {frf}}} were specified, the query would mean "do you have UPP available, for amounts denominated in French francs, at the URL specified in the HTTP request that contains this header").
In order to ask a more general question (such as "what payment choices are available for all URLs at your site") the for option must be used:
GET URL
Protocol-Query: {http://www.w3.org/UPP {for /*} upp-params}
Notice that in a for, the "URLs" ending in * are actually prefix strings. So the "/*" here means "any URL at your server that starts with '/'," which in turn means all URLs at your server.
The response to this HTTP message will fall into one of two categories:
A proper implementation of PEP requires that the protocol module associated with the specified protocol will be invoked when a Protocol-Query: line is encountered specifying that protocol. A proper implementation of the UPP protocol module will supply one of the responses indicated under Operation 2 (Present Payment Choices), indicating the payment options that the server wishes to advertise.
In order for the server to ask the client what payment choices are available, a similar mechanism is used. In this case, however, the server should use the {for } to indicate the parts of its URL space where payment might be discussed:
200 OK
Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*}
upp-params}
Technically, this is a way for the server to ask the client to reveal payments choices a user will consider for URLs that begin with /PaymentPages/. The client will reply (at least) whether the protocol can be used for the resource of the response, and (optionally) whether it might be used elsewhere (the range the server specified, anywhere on that server, etc).
A proper implementation of PEP requires that the protocol module associated with the specified protocol will be invoked when a Protocol-Query line is encountered specifying that protocol. A proper implementation of the UPP protocol module will supply one of the responses indicated under Operation 2 (Present Payment Choices), indicating the payment options that the client wishes to advertise.
Then, the next time the client accesses any resource in the for list from the query, it will include its answer(s) to the query.
Either end should be able to list the forms of payment it supports. Notice that this may not be a complete list, but rather a list of options that it "prefers" at the current moment. This list may be presented in response to a request (operation 1) or spontaneously. The latter behavior is analogous to the use of "logo stickers" on a store window or cash register.
JEPI implementors: the demo will only require this operation in response to a specific request.
This operation is performed by adding one or more Protocol-Info: headers to the HTTP packet. If the list is being presented in response to a request (operation 1), PEP requires that it include a header in the following form:
200 OK -or- GET ...
Protocol-Info: {http://www.w3.org/UPP [for] [{str strength}]
upp-params}
where the for should be the same as the for clause in the request (or omitted if it wasn't in the request); and the strength (if present) must be ref, req, or opt. The strength can be opt (or omitted) in any case; it may be ref only if payment won't be permitted at any of the URLs specified by the for clause; it may be req only if payment is required at all of the URLs specified by the for clause.
In addition, there should be Protocol-Info: headers for each of the payment systems that are to be presented to the other end. These will have the form:
200 OK -or- GET ...
Protocol-Info: {http://...payment-system... [for] [{str strength}]
payment-params}
where payment-protocol is the URL for the specific payment protocol, the for and strength are as discussed above, and the payment-params are additional parameters (including the UPP parameters) that are specific to the payment system.
For example, if a client receives the request:
200 OK
Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*}
upp-params}
and wishes to indicate that it can pay using VISA over SET and via CyberCash coins it might reply as follows (details of the payment-specific lines are not finalized yet):
HEAD ...
Protocol-Info: {http://www.w3.org/UPP {for /PaymentPages/*}}
{http://www.SET.org/PEPSpec
{params {upp {instrument-brand VISA}}}
{for /PaymentPages/*}}
{http://www.CyberCash.com/PEPSpec
{params {upp {instrument-type ECASH}}}
{for /PaymentPages/*}}
The merchant (server) may demand that the client choose a specific form of payment to be used to pay for items.
JEPI implementors: In the demo, this happens when the "invoice page" is sent from the server to the client; the demand indicates what components of the page will require a response with payment choice (operation 4). In the demonstration, this same invoice page will carry both the operation 2 and operation 3 headers together: the server will announce some of its payment options at the time it issues the invoice and requires that payment be accompanied by a particular payment choice.
As part of a standard server (successful) reply, it may deliver a page that includes references that will require payment (i.e. a "Pay Button" or "Pay URL"). These should be identified in the header of the response packet by asking the client to respond by initiating a UPP payment protocol sequence:
200 OK
Protocol-request: {http://www.w3.org/UPP {str req} {for /PayButton}}
Technically, this means that the server asks the client to use the UPP protocol (operation 4) whenever it asks for retrieval of the exact URL /PayButton from this same server. The {str req} is a hint to the client that if it doesn't use the protocol, the request for that URL will be refused. Thus, the client is not absolutely required to remember that it should use UPP with the specified URL - but a network roundtrip will be avoided if it does so.
The customer (client) can indicate the payment method to be used to make a payment. This normally indicates to the server that payment should actually begin, and the response will either be to accept (operation 5) or reject (operation 6) the chosen mechanism.
In practice, this will only happen when a client replies to an operation 3 request for payment method. It must then respond with two headers: one indicating that it is responding to a request to use the UPP protocol by choosing a compatible payment protocol, and the compatible protocol header itself. For example, if the payment choice is to use VISA over SET, then we might expect a response as follows:
GET ...
Protocol: {http://www.w3.org/UPP {via http://www.SET.org/PEPSpec}}
{http://www.SET.org/PEPSpec
{str req}
{params {upp {instrument-type CREDIT} {instrument-brand VISA}}
other-SET-params}}
The expected response is either an operation 5 (server accepts the choice of SET and VISA) or operation 6 (server refuses the choice).
It is expected that somewhere between receiving the operation 3 and issuing the operation 4 the client application will have to decide on the payment mechanism. Neither PEP nor UPP specifies how this happens. For the JEPI demonstration, it is assumed that the browser will intercept the request to access any specified payment URLs (from the for list of the required challenge) and will engage in a dialog with the user if necessary to produce the desired choice. This implies that what merchants might typically describe as the "Pay" button becomes the "Choose a Payment Mechanism and Pay" button.
The server, in response to a payment choice (operation 4), may accept the choice and initiate an actual payment operation. The payment operation itself is not part of the JEPI project and may or may not use PEP to handle the payment.
At this point, operation 4 has provided enough information to the server that it is willing to kick off the actual payment system. JEPI, PEP, and UPP provide no information on precisely how to do this, but there is one additional PEP/UPP header which can be optionally sent back to the client. If a normal MIME-based helper application is available to do the payment on the client side, then there is no need for the following header. On the other hand, a better user interface can often be produced if a helper application can be run while the client (browser) waits for the application to complete. To support this, UPP adds one final message from the server to the client. It provides the URLs that should be shown in each of three cases:
The header is as follows:
200 OK
Protocol: {http://www.w3.org/UPP
{params {upp {abort abort-URL}
{cancel cancel-URL}
{success success-URL}}}
The server, in response to a payment choice (operation 4), may reject the choice and request that another choice be made. UPP specifies that a rejection can occur either because the user canceled the transaction prior to completion or because the transaction failed for other (payment-system specific) reasons. They are distinguished and can result in different client actions.
If a client proposes a payment system that is not acceptable to the server, the server responds with a 400- or 500-class PEP error message. The body of the message should explain what went wrong as well as possible, including any explanation that the requested payment system may be able to supply. It should probably include a button to go back to the invoice page, if possible, but the browser's BACK button will work, too. The server should include one additional header on this message to reduce the chance that the same payment system will be tried a second time:
420 Client PEP Error -or- 520 Server PEP Error
Protocol-Info: {http://...payment-system...
{str ref} payment-params}
Followed by an operation 3 header
where payment-system is the payment protocol that is being rejected, payment-params are the parameters of the payment system which caused the problem, and pay-URL is the URL of the item just requested (i.e. the one that initiates the payment protocol on the server side).
The error code is distinguished mainly by whether the server has the protocol and doesn't accept it and the client should know better (422 Protocol Extension Refused) or if the server does not have it (521 Protocol Extension Not Implemented) or cannot get it to work (520 Protocol Extension Error or 522 Protocol Extension Parameters Not Acceptable). Other PEP error codes may be more specifically applicable for particular payment systems.
Either side can ask the other if it supports payment by a particular payment mechanism.
JEPI implementors: This is not currently required for the demonstration, but it might be a useful addition for the client to ask the server this question prior to counter-offering with a payment mechanism not mentioned by the server in its list of supported mechanisms (operation 2).
The PEP header Protocol-Query can be used by either party at any time to ask this question. As with operation 1, there is a technical meaning for the query that requires the other end to respond with a Protocol-Info response that is specific to the particular URL being queried, and the {for …} construct can be used to generalize the query.
Also as with operation 1 and 2, a proper implementation of a payment system module for use with UPP should provide additional information about where and with which parameters the payment system will operate when it is possible to do so. That is, a request for "do you support SET for VISA at URL /MerchantHomePage" must be answered "no" (unless payment happens on the home page), but a more thorough response will volunteer the information that such a payment is permitted elsewhere at the site.
200 OK -or- GET ...
Protocol-Query: {payment-system [payment-system-params]}
where payment-system is the URL of the payment system protocol,
and payment-system-params are parameters specific to that
protocol (including common UPP parameters).
In short, this protocol only addresses payment selection in the clear. Security of the overall payments process lies in other components.
Donald E. Eastlake 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Tel: +1 (508) 287 4877 (+1 703 620 4200 main office, Reston, Virginia, USA) Fax: +1 (508) 371 7148 Email: dee@cybercash.com Rohit Khare Technical Staff, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. Tel: +1 (617) 253 5884 Fax: +1 (617) 258 5999 Email: khare@w3.org Jim Miller Technology & Society Area Leader, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. Tel: +1 (617) 253 3194 Fax: +1 (617) 258 5999 Email: jmiller@w3.org
Copyright © 1997 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.