[payment agent] some initial observations

As I am new to this task force, I wanted to check that my understanding is roughly correct.

The main requirement is to support payment requests and refunds originating either from a merchant’s website, or from a payment terminal of some kind. This could include person to person payments where one person requests a payment from another with the phone emulating a payment terminal. A further requirement is the capability for cancelling transactions, and for handling a range of error conditions in a predictable way.

This points to the need for a standard interface for payment instruments for handling payment requests and refunds. This interface should be independent of how the instrument is invoked, e.g. from a web page or from a payment terminal.  The interface needs to be able to support a broad range of payment instruments as part of our goal to enable a level playing field.  Payment instruments may use additional back-end communication channels as appropriate to the needs of each instrument. This could include communication paths involving the merchant, issuer, acquirer and so forth. The interface needs to be asynchronous since the payment process may take time to complete.

The user payment agent (or digital wallet) is essentially a container for multiple payment instruments, and assists the user in routing the payment request/refund to a given payment instrument.  The digital wallet may support user preferences, e.g. to always use a given payment instrument in a given context, since this will improve the user experience by dropping the step where the user is asked to choose between multiple payment instruments that match the constraints set in the payment request.

Note that to limit the choices presented to the user to those that match the constraints, we will need a way for the user payment agent to test whether a payment instrument matches the constraints. This too should be an asynchronous interface since the payment instrument could be implemented remotely.  Joerg has suggested the use of a card metaphor in which each payment instrument is visualised as a card with a standard image size. Payment instruments should also provide a way to allow users to manage that instrument. This could be as simple as launching a web page or native app for the payment instrument.

I believe that Joerg and others have shown an interest in supporting vouchers, discount coupons and loyalty cards, as well as the potential role of the wallet as a container of identity cards. In principle, a payment instrument could also serve as an identity card, based upon trust that the card issuer has verified a set of the user’s real world attributes. See my blog post on linking web identities to real world identities.

I would like to get a better understanding of how vouchers, discount coupons and loyalty cards should be handled, starting by thinking about pertinent use cases that clearly set out the user experience. The user may be asked to make a decision, and this raises the question of what functional component handles the associated user interface. Some choices include: the merchant’s web page or payment terminal, the digital wallet, and the payment instrument selected for the payment transaction. The desire by merchants to control the associated user experience will be a factor in this.

There should to be a way to install/register a digital wallet, and likewise to unregister/uninstall a digital wallet. If there is more than one wallet registered, then presumably it is up to the browser to support the selection of a wallet in any given situation.  Analogously, the needs to a way to install and activate payment instruments, and likewise to deactivate and uninstall payment instruments.  However, although it might be desirable to standardise this, it isn’t essential, at least as a first step. The same applies to the opportunity for defining a set of capabilities for use by payment instruments, for instance, for key management and second factor based authentication.

The digital wallet may support synchronisation across the owner’s devices, although this is likely to be restricted to wallets from the same vendor. Standards for synchronisation across wallets from different vendors could be something for the future.  It should be possible to implement digital wallets as part of the web browser, as a native app, as a locally installed web app, or as a remotely hosted web app. The choice of implementation should be invisible to the API presented to web page scripts, and invisible to payment terminals. Likewise the communication technology used to connect the payment terminal to the digital wallet should be invisible to the wallet and payment instruments.

Sorry for the length of this email, but I hope it helps others as much as it has helped me to clarify what I think we are talking about.  I now have a better idea as to what I am looking for in the use cases.

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>