Re: Dealing with the NASCAR Syndrome for Web Payments

On 16 April 2014 13:16, Dave Raggett <dsr@w3.org> wrote:

>
> 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.


+1


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