Re: WP WG Charter review (zach)

On 10 July 2015 at 13:34, Zach Koch <zkoch@google.com> wrote:

> Hi all -
>
> I had an AI from the call on Monday to review the working group draft
> charter. Comments:
>
>
>> Easier integration of new payment schemes by payment service providers,
>> increasing merchant acceptance.
>
>
> I'm not sure I understand fully how this goal will be realized, especially
> given the planned deliverables. What is being proposed that would make it
> easier for, say, Stripe (payment service provider) to accept Bitcoin (new
> payment scheme)?
>
>
This standard will make it easier for payer and payee to agree on a payment
instrument and because the dicovery process is using machine readable
messages (lists of instruments) the list can be very long. This means
payment service providers like Stripe could add new supported instruments
and merchants don't have to do anything (potentially).

As a merchant, I simply integrate with Stripe and then every time they add
a new instrument it automatically gets sent up in the payment initiation
request.

So, to some extent you are right. The integration by the service providers
is not necessarily easier but the merchant experience and increased number
of instruments merchants can accept is a big benefit.

Happy to reword this, any suggestions?



> Increased scope for digital wallet innovation by banks, retailers, mobile
>> operators, card networks, and other wallet providers
>
>
> Same fundamental comment as above. How are we affecting the innovation
> that is possible by banks, retailers, etc given planned deliverables?
>

Per my last mail, I think we are allowing a wallet vendors to be very
innovative and find ways to add value to their wallet services as a
differentiators from the competition. I expect all of these (banks,
retailers, mobile operators, card networks) to want to be wallet vendors.


>
> "Web context"
>
>
> Agreed with Manu on another thread that "context" here is not necessary.
>

+1 Dropped


>
> The interfaces between the payment schemes and the Web are via the user
>> agent and the Web application, therefore the scope of the initial charter
>> is focused on the interactions between these two components and the
>> external actors that will interface directly with them.
>
>
> I'm not entirely sure what this sentence means. Aren't we focused on the
> interaction between three components: user agents, payment schemes (via a
> wallet), and a web site?
>

I added a flow diagram to the charter to try and illustrate this a little
better. Let me know if still unclear or if this could be re-worded.


>
> Wallets
>>
>
>
> It may hold one or more balances of some digital asset that can be used to
>> make payments.
>
>
> Why would the Wallet need to have any notion of a balance? Shouldn't all
> of that be contained within the payment instrument within the Wallet? I
> think this bullet vastly expands the scope and capabilities of the "digital
> wallet" and is not something we want to standardize at this point.
>

Per my last email about PayPal; the PayPal wallet can hold instruments
(like cards or links to a bank account) or be an instrument itself. This is
because from the perspective of a merchant they can support PayPal as a
"way to pay" (payment instrument) where they get paid via PayPal and have
no idea what the funding source was.

The funding source could have been a PayPal balance.

With this standard in place the PayPal wallet could be used even if the
merchant doesn't explicitly support PayPal aslong as the merchant supports
one of the instruments the user has registered in their PayPal wallet.


>
> The group intends to create a standard interface from the Web to a user's
>> wallet so that a user with any conforming wallet can seamlessly make
>> payments with any conforming Web application running in a conforming user
>> agent.
>
>
> This seems overly broad. There are two limiting functions to consider: 1.)
> A payment can only be made so long as there is an intersection between the
> set of payment schemes a web site supports and the set of payment schemes
> available in a user's wallet. 2.) Certain contextual restrictions may make
> it such that *any* wallet working in *any* user agent is not necessarily a
> viable option.
>
> I would propose the following: "This group intends to create a standard
> interface from the Web to a user's wallet so that a user can seamlessly
> make payments from a conforming web application running in a conforming
> user agent."
>

I agree that the intersection of instruments is important but isn't that
covered (implied) by other parts of the standard (specifcally the new flow
diagram)?

The suggested sentence sounds wrong, wouldn't we make payments "to" a
conforming Web application? Happy to use the suggested version if we're on
the same page.


>
> The group will also consider the use case where a wallet serves as an
>> aggregator of other wallets, which should increase user choice of payment
>> solutions.
>
>
> This seems confusing from a user experience perspective, and it doesn't
> seem necessary to me.
>

As discussed in my last mail I think this is important to prevent wallets
becoming silos where user's must find a single wallet that supports all of
the payment instruments they have.


>
> Thanks,
>
> Zach
>