Re: The case for registration as a technical specification

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