RE: The case for registration as a technical specification

J  A hardy +1. Thanks Adrian – we nailed it to the precise point!  J

 

-- 
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+16145601237 | VOIP: HYPERLINK "tel:+16144656654"+16144656654 
Oracle Global Industry Solutions Group
New York City | | Columbus, Ohio

 

o-corp-tagline-badge-digital-clr

 

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com] 
Sent: Tuesday, July 14, 2015 4:04 PM
To: David Jackson
Cc: Joerg Heuer; Brett Wilson; David Baron; Web Payments IG; Zach Koch
Subject: Re: The case for registration as a technical specification

 

+1 - It would be great if further discussion on the charter referenced sections that were under discussion and provided specific suggestions for changes as well as the reasons.

Sweeping general statements are hard to contextualise with the charter document itself and how they should influence my editing thereof.

 

On 14 July 2015 at 12:13, David Jackson <HYPERLINK "mailto:david.dj.jackson@oracle.com"david.dj.jackson@oracle.com> wrote:

This is precisely the issue. The conversation doesn’t always seem to match the topic and draws some readers off into the weeds about the functionality of certain aspects – in this case, the wallet. And the conversation seems to draw people into how the wallet works (references to customer experience and the like) which infers – or seems to – draw the conversation into standardizing the wallet functionality. So, yes, I mean the conversation appears to draw the reader to the conclusion that we are trying to standardize the wallet and therefore extend the standard into that space. Maybe it is my reading of the amount of discussion on the topic, but that is my feedback. Maybe we are just spending too much time discussing wallets, customer experience, and functionality within the wallet which – as you state here – is  not part of the standard. IMHO

 

-- 
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+16145601237 | VOIP: HYPERLINK "tel:+16144656654"+16144656654 
Oracle Global Industry Solutions Group
New York City | | Columbus, Ohio

 

o-corp-tagline-badge-digital-clr

 

From: Adrian Hope-Bailie [mailto:HYPERLINK "mailto:adrian@hopebailie.com"adrian@hopebailie.com] 
Sent: Tuesday, July 14, 2015 2:38 PM


To: David Jackson
Cc: Joerg Heuer; Brett Wilson; David Baron; Web Payments IG; Zach Koch
Subject: Re: The case for registration as a technical specification

 

It's not clear to me whether you are making an observation regarding the conversation in this thread or requesting a change to the charter.

Your previous email referred to conversation around the beginning and end of the payment which I interpret as being related to the flow (which has a beginning and end).

Now, if I understand correctly, you are talking about whether or not we should be standardizing the wallet. If that's your point then my answer is no. We are standardising the interface to the wallet in the form of a set of request and response pairs the wallet must process and return and the format of these messages. We are not trying to standardise the functionality of the wallet, it can function any way it wants to as long as it processes the request messages and return appropriate responses.

 

On 14 July 2015 at 10:25, David Jackson <HYPERLINK "mailto:david.dj.jackson@oracle.com"david.dj.jackson@oracle.com> wrote:

The flow of use of a wallet is and has always been clear from the work I did 20 years ago in building a payment wallet. The question was that the conversation seems to drift into standardizing the wallet behavior which is what concerns me. We all seem to want choice in the way that the standard will work, but the conversation thread does seem to drift very deeply into where the standard starts. It is not clear that the wallet is or is not part of that standard and then it seems there was a great deal of conversation around how to enforce standardization on the wallet which appeared out of scope because it would reduce choice. Much the same as the discussion proceeded during the F2F. Therein lie my comments. Wallet flow isn’t related to the nature of the observations.

 

-- 
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+16145601237 | VOIP: HYPERLINK "tel:+16144656654"+16144656654 
Oracle Global Industry Solutions Group
New York City | | Columbus, Ohio

 

o-corp-tagline-badge-digital-clr

 

From: Adrian Hope-Bailie [mailto:HYPERLINK "mailto:adrian@hopebailie.com"adrian@hopebailie.com] 
Sent: Tuesday, July 14, 2015 12:55 PM
To: David Jackson
Cc: Joerg Heuer; Brett Wilson; David Baron; Web Payments IG; Zach Koch


Subject: Re: The case for registration as a technical specification

 

David,

The trigger for the beginning of the process is the payment initiation request from payee to payer. This request will contain the proposed terms (price, currency etc) and the list of supported payment instruments.

The payer's wallet will do whatever it needs to do to guide the user through the process of confirming the terms and selecting a payment instrument. This is where wallets can innovate around the UX and support for various instruments. Ultimately the payment initiation response is sent back confirming the terms and letting  the payee know which payment instrument the payer has selected to use.

No "payment" has been made yet but we've agreed on terms.

If the payer selected a payment instrument that is processed by the payee (like a credit card) then the payee passes the message on to their payment gateway or payment services provider. Let's assume it was a credit card, then the credit card scheme would define the data that the payer wallet must send in that message. It may be a token representing the card or an encrypted card number or even a reference to an exchange of data that was done out of band by the wallet service with some 3rd party (up to the scheme to define and the wallet to support).

The next step is a final exchange of completion messages. 

If the payment instrument is "payee initiated" (example: credit card) then we assume that the payment gateway/service provider has processed the payment and this will be the confirmation.

If the payment instrument is "payer initiated" (example: bitcoin) then the completion request is the instruction to the payer to send the payment. The completion response will be the confirmation from the payer that this is done.

Is there still a part of this flow that's unclear or that you feel needs to change?

Adrian

 

On 14 July 2015 at 04:46, David Jackson <HYPERLINK "mailto:david.dj.jackson@oracle.com"david.dj.jackson@oracle.com> wrote:

In this discussion, it seems we have slid back into defining the beginning of the “payment”. We discussed the end with respect to receipt quite a bit and concluded that. Now it seems we are conversing about the beginning of what defines the payment. Maybe we should agree to the beginning of the actual payment, and then discuss if we should go further into the definition of the user selection of payment instrument (wallet) function. I see these as two different issues which we may – or may not – wish to address in the standard. The easiest way to start is to choose the beginning of the process to be standardized and the end. I do realize that we discuss the payment selection as part of the standard in the use cases, but maybe that should be left silent for the start – then we can incorporate what we wish of the selection after the standard of the payment from after selection to the “end” which was discussed previously.

 

-- 
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+16145601237 | VOIP: HYPERLINK "tel:+16144656654"+16144656654 
Oracle Global Industry Solutions Group
New York City | | Columbus, Ohio

 

o-corp-tagline-badge-digital-clr

 

From: HYPERLINK "mailto:Joerg.Heuer@telekom.de"Joerg.Heuer@telekom.de [mailto:HYPERLINK "mailto:Joerg.Heuer@telekom.de"Joerg.Heuer@telekom.de] 
Sent: Tuesday, July 14, 2015 6:33 AM
To: HYPERLINK "mailto:adrian@hopebailie.com"adrian@hopebailie.com; HYPERLINK "mailto:brettw@google.com"brettw@google.com
Cc: HYPERLINK "mailto:dbaron@dbaron.org"dbaron@dbaron.org; HYPERLINK "mailto:public-webpayments-ig@w3.org"public-webpayments-ig@w3.org; HYPERLINK "mailto:zkoch@google.com"zkoch@google.com
Subject: RE: The case for registration as a technical specification

 

Hello all,

 

Although I feel a bit awkward referring to PayPal all the time without them being present, we have been haggling with the same type of question in our work. And basically we came up with letting PayPal (or any other similar payment service) decide for themselves. In our concrete implementation using virtual cards, two options were available:

·         PayPal introduces a ‘PayPal Card’ acting like a payment instrument. The pre-configured funding source (or some automatism in their service backend picks one according to their rules) is used automatically. Transparency about which one gets used might be a feature of that specific ‘virtual card’ or not.

·         PayPal regards themselves as a wallet-in-the-cloud, supports the APIs and protocols we are defining and offers to the user to register the ‘PayPal Wallet-in-the-Cloud’ in their browser or OS.

 

Clearly both options would have advantages and disadvantages at the same time to PayPal, but they have a choice. They could also combine both options – or (kind of rightfully) state that they can create a much more consistent payment experience within their own universe and leave things as they are. Or even combine this stance with either of the options above.

 

I thought that showed that the architectural approach was pretty fine… I wouldn’t want to argue the different business and strategic implications, but taking a look at them shows you whether you might meet people’s interests and requirements in the end.

 

Cheers,

                Jörg

 

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com] 
Sent: Dienstag, 14. Juli 2015 02:14
To: Zach Koch
Cc: Brett Wilson; L. David Baron; Web Payments IG
Subject: Re: The case for registration as a technical specification

 

 

 

On 13 July 2015 at 16:23, Zach Koch <HYPERLINK "mailto:zkoch@google.com"zkoch@google.com> wrote:

There's a lot happening in this thread, so I apologize in advance for cherry picking out quotes and responding, but it seems like the cleanest way to do it.

 

As a general comment, the concept of a "wallet" and a "payment instrument" is becoming more and more muddled. I think this is worrisome, which I comment on more below. I thought of a wallet as something much dumber (i.e. just an aggregator of payment instruments).

 

I don't think it should be muddled but the PayPal case confuses things. I think there is a misunderstanding which I'll try to clarify.

The wallet can't just be an aggregator otherwise you have to define an instrument for every payment service provider and merchants have to explicitly support each of them. See my comment on Coinbase below.

 

 

I don't agree. PayPal hold a number of sources of funding (PayPal balance, credit cards etc) which are each payment instruments. I can see the argument that your PayPal account could advertise itself as a payment instrument but that takes away the ability of the payer to choose which instrument to use each time they pay out of their PayPal wallet.

 

I agree with David. PayPal is best thought of as a (set of) payment instrument(s). This notion of Visa, MC, PayPal etc all being wallets does not, IMO, lead to a good user experience. You're asking users to think about and understand the difference between Wallets and the various payment instruments they support. 

 

+1 PayPal is best thought of as a set of payment instruments (a wallet). 

I am not suggesting that MC or Visa are wallets (not sure how you read that from my response). I am suggesting they are payment instruments in the PayPal wallet.

BUT PayPal can be an instrument too because you can have a PayPal balance without needing to have any cards loaded in your PayPal wallet (someone sent you money).

So, as a user I can have my PayPal wallet loaded with a balance of $10 and also have a bunch of cards registered in there. If I visit merchant A website and he only supports VISA as a payment instrument my wallet supports the payment because it is holding a VISA payment instrument (note the merchant doesn't explicitly support PayPal as a payment instrument). When I visit merchant B website and she supports VISA, MC, Amex and PayPal my wallet can prompt me to use the instrument that I'd like to use for this transaction. Because the merchant explicitly supports PayPal I can use my PayPal wallet's balance and not one of the other registered instruments.

 

 

It also means that the merchant has to explicitly support PayPal as a payment instrument. If the merchant supports VISA cards as payment instruments and you have a VISA card in your PayPal wallet then you should be able to complete the payment.

 

Maybe, but I'm not sure PayPal would agree with you.


If a merchant accepts card payments via some other gateway (not PayPal) and I have my credit card loaded on PayPal I can't use that PayPal wallet to pay today. I have to enter my card details directly into the website and PayPal are not involved.

 

If we have this standard in place then my PayPal wallet can send my VISA card details to that merchant's gateway (in whatever form the VISA scheme dictates) and I can complete the payment. This is the advantage of the standard we are proposing. I think PayPal would like the world where merchants don't have to explicitly support PayPal and yet users can still use a PayPal wallet. 

 

This is the goal, decouple the wallet and instrument to some extent so that merchant's don't have to support wallets just payment instruments. Then the user's can use whatever wallet they choose and still be able to pay at most merchants.

 

 

We are explicitly aiming to create a standard that allows some kind of aggregation so the line between wallets (which are effectively aggregators of instruments) and instruments does become a bit of a grey area.

 

This is a big red flag to me and worries me that what you'll end up with is a muddled and confusing user experience. We need to draw a clear line between a "wallet" and a payment instrument.

 

It will only be confusing for users with complex requirements. Most users will pick a single wallet that supports all the payment instruments they have.

I'd see it as a kind of heirarchy where the browser only needs to interface with a single wallet which the user configures as their default wallet. If that wallet doesn't support some obscure payment instrument that they want to use then instead of putting that instrument into their default wallet they can have a second wallet which does support that instrument and put the second wallet into wallet their default wallet.

There is no easy way to get away from the browser or other user agent having a single entry point to kicking off the payment instrument discovery process. This is addressed by having a default wallet. BUT to prevent user lock-in we need to allow users to have mutiple wallets so we need to allow that default wallet to aggregate other wallets if that's what the user wants.

 

 

The major difference between a wallet and simple list of instruments is that wallets have knowledge about how to use the instruments they support storing. 
A wallet that supports Bitcoin knows how to send a Bitcoin transaction for example. 

 

I'm not clear on why this has to be the case.  Couldn't you have Coinbase, for example, as the payment instrument and the Coinbase payment instrument knows how to send a bitcoin transaction? Why does the Wallet need to know about this? I think we're overcomplicating the Wallet here.

 

If you do this then the merchant has to support Coinbase.

Wouldn't it be better if the merchant just supported Bitcoin? Then the user can use whatever wallet they choose that supports Bitcoin.

That's not to say the merchant can't support Bitcoin AND Coinbase if there are some features of the Coinbase payment instrument they'd like to explicitly support.

In this scenario Coinbase is a wallet. It's not a very useful one because it only supports Bitcoin but it could be one of the more obscure ones that user's put inside another.

If you revisit the PayPal example imagine that one of the payment instruments I have added to my PayPal wallet is my Coinbase wallet (the PayPal wallet is aggregating the instruments of another wallet because I chose PayPal as my default wallet but they don't support Bitcoin so I had to add my Coinbase wallet INTO my PayPal wallet). So I now have a PayPal balance, a bunch of cards and a Bitcoin wallet as possible payment instruments. The merchant doesn't need to support PayPal or Coinbase they could simply support VISA and Bitcoin and I already have two ways I can pay them.

 

 

If schemes define rules that close out wallets then the market will push back by tending toward more open schemes. A standard like this enables this market driven openness because it becomes trivial for merchants and users to support and use new payment instruments.

 

It seems as if you're making Wallets the key place where innovation happens here. I don't think that's the right place. I understand the goal of driving openness, but I'm not sure this standard is the place to push this. I think first we should focus on users and creating an easy and compelling user experience (i.e. easy selection of payment instruments from the intersection of payment instruments they've added to their wallet and payment schemes the merchant supports). Then we should focus on merchants and ensuring that the payment schemes they accept are available in this new experience we're standardizing. We shouldn't be trying to force PayPal, for example, to support credit card transactions for non PayPal merchants. I fear that will not end in success.

 

I disagree. I hope from my explanations above you can see why. If PayPal adhere to this standard for their wallet then it is possible for merchants to accept card payments from users with a PayPal wallet even if the merchant doesn't support PayPal.

If PayPal doesn't want to adhere to the standard the market will force them out as people realise that they can't use their PayPal wallet at many sites and find other wallets that adhere to the standard.

 

 

 

On Mon, Jul 13, 2015 at 3:53 PM, Adrian Hope-Bailie <HYPERLINK "mailto:adrian@hopebailie.com"adrian@hopebailie.com> wrote:

 

 

On 13 July 2015 at 11:31, Brett Wilson <HYPERLINK "mailto:brettw@google.com"brettw@google.com> wrote:

On Mon, Jul 13, 2015 at 4:25 AM, L. David Baron <HYPERLINK "mailto:dbaron@dbaron.org"dbaron@dbaron.org> wrote:

On Thursday 2015-07-09 17:34 +0200, Adrian Hope-Bailie wrote:
> Hi David,
>
> I agree and I think that the discussion re the charter to date suggests
> others do too.
>
> One thing I wanted to clarify is the role of the browser/UA in the
> currently proposed flow. This is my understanding and I'm happy for anyone
> to chime in with a different perspective.
>
> As it stands, the proposal is to create a standard WebIDL API that allows
> websites to initiate a payment by passing a standardised message to the
> browser and for that API to respond with a standardised message back to the
> website. This process will be repeated for a completion request and
> response.
>
> When the browser receives this message it should do one of two things:
>
>    1. Pass it directly to a configured wallet, unmodified
>    2. Decline the API request as there is no wallet configured
>
> i.e. I'd like the browser's participation in the flow to simply be as a
> proxy of messages between the website and the user's wallet.
>
> We are proposing that there may be 3 types of wallet:
>
> 1. Cloud-based. In which case the browser passes the requests message via
> HTTP (a REST API of sorts) to the wallet service and get's back a response.
> (Details of how this would work, including hosting of the wallet UI in a
> frame or new window will be left to the WG to decide).
>
> 2. Native. Meaning the user installed some wallet software (or app in the
> case of a smartphone) and there is a mechanism for the browser to
> communicate with that native wallet service. It will be for the browser
> vendors to propose how this is done or if it should be standardised.
> Perhaps it will be simplest to say that native wallets must host an HTTP
> endpoint service so that the interface matches cloud-based wallets, or
> maybe they will need to take the form of browser extensions.
>
> 3. Built-in to the browser or OS. In this case I think it's outside the W3C
> WG's scope to define the delivery mechanism for messages between the UA and
> the wallet service but the standard could still mandate that the messages
> passed between the UA and wallet must follow the standard format.

Saying that there can be three different types of wallet and not
defining how they really work seems dangerous to me.  It makes the
wallet concept like a black box, which means an essential part of
the system is not defined by the standard, and thus unlikely to be
sufficiently open.

 

Need a "wallet" by anything more than a list of payment instruments?

 

Yes.

As I said to David, wallets need to know how to use a payment instrument according to the rules of the scheme for which the instrument is issued. 
 

I would expect the system to have a list of payment instruments provided via a system-specific API. 

 

Why system specific? The standard is aiming to define a set of standard messages that the wallet must process and a set of standard responses the wallet must return. The actual delivery mechanism may differ but the messages and flow will be standardized.

 

Likewise, the browser might maintain some web payment instruments in its own database that it merges with system instruments to display to the user. 

 

Why would the browser display the list of instruments to the user? The intention is for the browser to simply be a proxy of messages between the wallet and the calling application.

If the wallet is built into the browser then it may be the component that prompts the user but if it is not then I'd expect the wallet service itself to display this UI.

The "merging" you describe is what we have called an aggregation service but I'd recommend that the browser doesn't attempt to do this but rather allow user's to configure the browser with their preferred wallet.

Browser can take on this role if the user hasn't explicitly configured another wallet and I'd recommend that the standard makes it mandatory to allow users to pick a wallet other than the browser.

 

How these are stored or retrieved in any particular situation isn't something that can or should be standardized.

 

 

Correct. Wallets are free to store and retrieve instruments and the meta-data they require as they wish. Some schemes will define how this must be done if the data is sensitive.

 

Alternatively the mechanism that is used may be a competitive differentiator for a wallet. Example: a wallet that supports Bitcoin may support a sophisticated multi-sig or hardware-based mechanism for executing transaction.

 


 

I think the term "wallet" is confusing since it gives the impression that there's a thing people can point to that has specific properties. I would personally prefer if it was just replaced with "list of payment instruments" every time it appears.

 

 

The wallet is a thing that people WILL point their browser to that does have specific properties. The most important will be that it supports the APIs we are defining. It is NOT just a list of instruments. It maintains a list of instruments that the user has registered but also has knowledge about how to use those instruments.

 

Brett