Re: Comments on Charter

On 15 July 2015 at 08:47, Mountie Lee <mountie@paygate.net> wrote:

> Hi.
>
> I added comments for charter at
>
>
> https://docs.google.com/document/d/1wsvqY_wvhqG77OXh1JaPUJiU9TX3H-KfVYBqzVP2J6I/edit?usp=sharing
>
> followings are summary of my comments
>
> Note: For more information about roles involved in this payment flow
> (payer, payee, etc.), please see the Web Payments Interest Group's
> glossary
> <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#terminology>
> .
>
> ==> is this correct link for Glossary? it linked to usecases.
>
> Where practical the standards will be usable by native applications/apps.
>
> ==> this will mis-lead using native apps.
> suggestion : "web applications including native applications/apps"
>

The intention is to note that where possible the standards will be usable
by native apps BUT this is not the group's focus will give some thought to
how we can reword this to be clearer.


>
> Easier integration of new payment schemes by payment service providers,
> increasing merchant acceptance.
>
> ==> can we use "payee" instead of merchant?
> I'm thinking merchant, vending machine
>

+1 for consistency


>
> The interfaces between the payment schemes and the Web are usually at 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.
>
> ==> if we consider multiple user agents, the interfaces will be more
> complex than single.
> but we have to consider multiple user agents in the payment flow.
>

I'm not sure I follow this logic. How will a single payment involve
multiple user agents? What use case are you thinking of here?


>
> Registration, by the payer with their wallet
> <http://w3c.github.io/webpayments-ig/latest/charters/payments-wg-charter.html#wallets>,
> of any conforming payment instrument they wish to use on the Web (e.g. a
> credit or debit card, electronic cash, cryptocurrency, etc).
>
> ==> Pre-Payment can be initiated by payee or payer
> and Registered only by payer with their wallet.
> I'm thinking registration can be processed at the same time of "Payment
> Initiation Request" by the payee.
> suggest to add "registration requested can be initiated by payee"
>

This is not referring to pre-payment. It is just registration of the
payment instrument with the wallet service. It's the equivalent of putting
a new card in your wallet. If it is a pre-paid payment instrument then the
pre-payment is a separate process.

Can you explain or point me to the use case where pre-payment is initiated
by the payee, it might mean I need to adjust other steps in the flow.


>
> the accepted payment schemes, price, currency, recurrence, transaction
> type (purchase, refund etc.)
>
> ==> hope to add "timeout, callback address"
>

Have added timeout.
I think callback is a protocol specific element of the messaging and will
be added if the protocol we design requires it.
I don't want to presume we will need callbacks (even though it seems
likely) and I don't think we lose anything by not having it here.


>
> Negotiation of Payment Instruments
>
> ==> do we exclude "Selection of Payment Scheme" which is higher level of
> payment instrument?
>

I think selection of scheme is inferred by selection of instrument. Would
you agree?


>
> Discovery, by the payer, of their available payment instruments that can
> be used to make the payment. This is done by matching those registered by
> the payer with those supported by the payee (as defined in the Payment
> Initiation Request), while keeping information local to the payer
>
> ==> discovery is combination of registration.
> will these flow be bound to user agent level?
> how to make discovery between multiple user agents of payer?
> just with single user agent, the view is clear.
> but with multiple user agents, the view is not clear.
>

I am unsure what you mean by multiple user agents. Can you explain or give
an example of how this would work?


>
> An example basic payment flow where messages are proxied via a user agent
>
> ==> I'm trying to draw the payment flow with sequence diagram style.
> the diagram is quite complex.
>
> suggest to replace diagram with thishttp://bit.ly/1DgWanG
> <http://www.google.com/url?q=http%3A%2F%2Fbit.ly%2F1DgWanG&sa=D&sntz=1&usg=AFQjCNE5fm8Cndh6SrtWeaT8uF3JjzDFNw>
> [image: Inline image 1]
>
>
Happy to discuss the best diagram format. I like that this includes
registration.
Let me know what you think of the diagrams I sent ealrier.


>
> The group will also address exceptions that may occur during these steps,
> including payment authorization failure.
>
> ==> one of most important exception is timeout control.
>

Yes, have added timeout as you requested earlier


>
>
>    -
>
>    It holds and allows access to payment instruments registered by the
>    payer.
>    -
>
>    It provides logic to support certain payment schemes and enables the
>    payer to use registered payment instruments to execute a payment in
>    accordance with the rules and processes of that scheme.
>    -
>
>    It may hold digital assets, in the form of one or more account
>    balances, that can be used to make payments.
>    - It may enrich the payment flow by implementing business logic for
>    loyalty, coupons, ticketing or other function that is complimentary to its
>    payment capabilities.
>
> ==> we need to clarify wallet ownership.
> we can image two cases.
> * server side wallet which hold digital assets and wallet client will be
> located at user agent side.
> * client side wallet which hold digital assets at user agent side.
>
> by the difference of wallet location, the payment flow will be different.
>
> the entire description of charter should contain both cases.
>
> suggestion: add "It may be located at user agent side or server side with
> front interface of user agent."
>

I think we do cover this in the notion of native vs embedded vs cloud-based
wallets.
We are aiming for a flow where this makes little difference.

The user-agent is a proxy and it directs messages to the wallet via some
local interface if it is client side or via Web services if it is cloud
based.


>
> The Working Group will develop machine-readable vocabularies that enable
> the following
>
> ==> this is quite sensitive issue. how we manage lifecycle of
> vocabularies?
> if new payment scheme appeared, how it can be added to the list? (after
> closing WG activities)
>
> suggestion: "The Working Group will develop machine-readable vocabularies
> and mechanism to manage lifecycle of vocabularies ..."
>

+ 1 added


>
> ------------
> ==> added Cash Payments with Escrow 1.0 (optional)
>
> Cash Payments with Escrow 1.0 (optional)
>
> Large proportion of payments on the Web are conducted using cash with
> escrow (for payer protection).
>
> The group should attept to define a standardized payment flow specifically
> for cash with escrow.
>
> A generic cash payment with escrow standard could:
>
>    -
>
>    Demonstrate initiation of escrow on payer choice, release of escrow
>    with user consent.
>
>
> escrow for payee proection can be standardized at another version.
>
>
I like this but I want to challenge you that the release of escrow is
outside the payment flow.
Would you agree?

In the payment flow I'd argue that payer and payee agree on an escrow
service and get some kind of reference for the transaction so that the
payer can release the payment later and the payee can link the transaction
to the order.


>
>
> --
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
>
>