Re: The case for registration as a technical specification

After seeing your diagram on the charter I think I understand how you mean
this to work now.

Brett

On Mon, Jul 13, 2015 at 5:54 PM, Brett Wilson <brettw@google.com> wrote:

> On Mon, Jul 13, 2015 at 5:14 PM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>>
>> On 13 July 2015 at 16:23, Zach Koch <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.
>>
>
> I'm quite confused about your proposal. How does money transfer in this
> case from MasterCard in your PayPal wallet to my web site? A merchant has
> to have a relationship with somebody that the user interacts with to get
> paid. Say the merchant processes their payments through Stripe. The user
> has a PayPal "wallet" and selects a MasterCard instrument. Can you walk me
> through how the merchant gets paid?
>
> Brett
>