Re: Dealing with the NASCAR Syndrome for Web Payments

On 15/04/14 16:40, Jorge Zaccaro wrote:
> Dave,
>
> I agree that there's a 'need for an open standard that decouples web 
> pages from wallets and payment solutions', and that's why I started 
> working on a WebWallet API 
> specification (https://github.com/playbanq/webwalletapi) and joined 
> the WebPayments group last week to learn where things are being headed 
> to. I'd love to learn more about the group's opinions and vision on 
> wallets for the Web.
>

Hi Jorge,

Thanks to the pointer to your proposal. It defines a RESTful interface 
to a cloud based wallet, but it doesn't define how to decouple web 
applications from wallets, nor does it define the user interface for the 
wallet (e.g. for checking the balance or adding funds).

Decoupling web applications from wallets would involve a means for apps 
to request payments, a means for users to register and unregister 
wallets, and a means for users to select which wallet to use for a 
payment request if multiple wallets are registered.

For registration, a wallet could be identified by a URI. That leaves 
open the nature of the interface between the browser and the wallet.  
One idea, as you suggest, is to define a RESTful interface for payment 
requests.  However, there is also the need for a user interface to the 
wallet, and the least constraining way to support that is as a web 
application. The user experience and functionality of the wallet would 
then be up to the implementers, who would be free to innovate and 
distinguish themselves from other wallet implementations.

Following the precedent set by web intents, if a user visits a wallet 
application, the application register itself, subject to confirmation by 
the user. The browser itself would need to provide a means for users to 
review which wallets are currently registered and to unregister any of 
them that the user chooses.

Physical wallets typically contain multiple means of payment, and we 
should allow the same for virtual wallets. This implies a need for the 
wallet to present a user interface to allow the user to choose how to 
pay for a given payment request.  This too could be realized as a web 
application.

A further question is how this application is handled by the browser, 
for instance, does it take over the browser window/tab (or screen on 
mobile devices) or does it execute within an IFRAME element?  The latter 
could be appropriate on desktop page layouts, and suggests the need for 
the web application to optionally pass an IFRAME element as part of the 
payment request API.

The lesson from web intents is the need to define what happens under 
various abnormal conditions, e.g. when the user closes the wallet's 
browser tab/window or presses "back" on the browser navigation chrome, 
or the wallet somehow crashes, e.g. if the network connection fails, or 
the device itself is turned off.  What if the web application requesting 
payment itself dies or is terminated before the user has completed the 
payment transaction through the wallet? What if the payment transaction 
succeeded, but the proof of purchase couldn't be delivered to the 
application that requested the payment?

The assumption above is that we want to encourage innovation and 
competition amongst wallet providers rather to limit wallets to a fixed 
functionality. This seems essential if we are to convince companies of 
the business case for open standards for wallets and the need for 
minimally constraining standards as a basis for decoupling web 
applications from wallets and payment solutions.

-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Wednesday, 16 April 2014 11:16:57 UTC