Re: Dealing with the NASCAR Syndrome for Web Payments

On 17/04/14 09:00, Jorge Zaccaro wrote:
> 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.

That is the challenge for the interface for making a payment request and 
getting back a proof of purchase.  The discussions I had around the 
workshop suggest that there is a reasonable chance of being able to 
standardize this starting with B2C.  The request will involve 
information on what means of payment the merchant accepts, including any 
applicable surcharges (e.g. for use of credit cards vs debit cards). The 
wallet app could then examine a range of alternatives to find the ones 
that best match the user's preferences.  This is especially relevant to 
cross border/cross currency payments, where the wallet app could examine 
options that would be too complex to present to the user directly.

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

This is where we need to consider what additional standards are needed 
as building blocks for wallet apps and individual payment solutions.  As 
an example, W3C is planning a workshop on stronger authentication, and 
moving beyond user name and password.  Other examples include work on 
access to secure elements, NFC and Bluetooth.  These building block 
standards are not specific to payments.

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

I think it will be harder for W3C to define open standards between the 
wallet and payment solutions, but luckily, that isn't a prerequisite. 
Wallet providers will need to work with existing and new payment solutions.

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

The browser would need a registry for the user's wallets. This could be 
quite simple as a list of URIs together with names and logos. The wallet 
apps could be cloud based, client based or some combination thereof.  
Client based solutions would involve some means for the browser to 
launch the client, perhaps using an AppURI.  In principle, the wallet 
could even be implemented as a native app and invoked e.g. via Android's 
intent mechanism.  Cloud based implementations present fewer challenges, 
and could be referenced  with an https URI.

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