Re: Dealing with the NASCAR Syndrome for Web Payments

Thank you very much for your feedback Dave, I find it really valuable,
specially because I hadn't thought about the decoupling problem yet.
Loosely coupling web apps and wallets would be a matter of
*interoperability* I guess, i.e. making sure that wallet providers allow
their users to request and send payments to wallets hosted in other clouds
(something like friending people across different social networks). This
would prevent web apps from being tied to a specific wallet provider by
embedding a vendor-specific payment button or form, and instead could
enable them to accept general wallet payments by embedding *vendor-agnostic
forms* such as those used for credit cards. However, that loosely coupling
would inexorably be constrained by the underlying banking infrastructure
(e.g. merchant accounts, payment processing networks) required to perform
the actual funds transfers between buyers and sellers (that might involve
different jurisdictions), so perfect decoupling would probably be really
hard to achieve.

As far as the user interface is concerned, I think it's very important to
take into account the various types of agents a wallet provider might be
interacting with, because in order to allow multiple means of payment they
would have to be able to carry out funding transactions in a uniform way
not only with credit cards and bank accounts, but also with mobile carriers
(via SMS), prepaid recharge networks (via PINs) and POS terminals taking
cash at general purpose stores, for example. Although it might be difficult
to get different agents to work with a Web API if they're not used to that,
I think this approach is very uniform and flexible, and would allow
different application servers to implement *customized user interfaces from
a well defined set of API calls* when they are ready to do so. The browser
handling would also be flexible and up to the web apps since making calls
to a Web API using HTML plugins and a JavaScript SDK imposes no
restrictions on using windows, tabs or iframes.

Regarding the abnormal conditions scenarios, I defined the WebWallet
transactions to be bilateral and based on tokens with an expiration date,
meaning that if one party initiates a transaction by obtaining a
transaction token, the transaction can only be completed by the other party
using the transaction token that was created by and received from the
initiator party. Besides enabling the creation of a secure system where
wallet IDs are public (e.g. URIs, mobile numbers), this *token-based
bilateral transaction approach* could handle deviations from the normal
transaction flow like pressing the back button or closing/crashing the
browser tab/window. As long as the transaction token was created and has
not expired by the time the user goes back to the web app after turning on
the device again, opening the browser tab/window and/or restoring the
internet connection, the web app should be able to complete the transaction
using the same transaction token or check its state by making an API call
to the transaction URI.

I totally agree that the goal is to encourage innovation and competition
amongst wallet providers rather than tying web apps to a specific wallet
with fixed functionality, and the way to do that is to create something
open and interoperable. I will incorporate these suggestions about
decoupling and user interfaces to wallets into the design of the WebWallet
API <https://github.com/playbanq/webwalletapi>, and off course I will be
open for exchanging more feedback as I continue to participate in the group.

By the way, one question: What do you mean by *"**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**"*? You
mean the wallets would be stored and handled by the browser via (offline)
web apps (e.g. chrome apps, firefox add-ons)? Or generally speaking about
(cloud-based) web apps?


On Wed, Apr 16, 2014 at 6:20 AM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

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