Re: [use cases] comments on fpwd

As a heads-up to members that are new to W3C work, this is typically how
an editor of a document processes review comments (either from other W3C
members or from the general public, the process is more or less the same).

On 01/16/2015 03:19 AM, Stephane Boyera wrote:
> I have just reviewed the use-cases that are in the FPWD 

Thanks for the review, Stephane. Feedback to your comments below:

> *Purchase Request This use-case is a bit surprising for me, as I
> feel it covers multiple other cases. Somehow I feel it is a
> meta-use-case that includes at least "choice of payment instrument"
> and a type of payments (push-based, token-based, cc info exchange).

Isn't the choice of payment instrument and the type of payment the same
thing? Whether you use push-based, token-based, or send credit-card info
is entirely dependent on the type of payment instrument, right?

I tried to make the use case only about the payment request. For
example, I left the details of how a payment instrument is
negotiated/specified to the "choice of payment instrument" use case.

I'm a -1 on meta use cases because it seems like we're going to be doing
those in the Payment Agent and/or Roadmap document and because I think
they'd be hard to follow in the use cases document. My other
concern w/ meta-use cases in the use case document is that you can make
an argument for most high-level use cases as being meta use cases
because there is always some detail that lives elsewhere. I think we
should cross-link the use cases where it makes sense to do so. I may be
in the minority wrt. these opinions about meta use cases, though, so
what do others think about them?

I did create a link from this use case to the "choice of payment
instrument" use case, and made a note about creating another link to the
"Offers" and "Digital Signatures" use cases (if they make it into the
document). I think that achieves some of what you wanted, but that might
not be enough of a change for you?

> Possible suggestions: -we don't put it as a use-case but describe it 
> as an integration use-case where we put all other use-case

I think we're going to be doing "integration use cases" in the Payment
Agent or Roadmap documents. I cross-linked to other use cases which may
be enough?

> -we change a bit its content to focus only on the elements not 
> covered in the other use-cases (e.G. request description, 
> receipts,...)

I created some links to the other sections that don't have to do with
the payment request (namely, the offer use case and the choice of
payment instrument).

Here are the diffs based on your feedback:

https://github.com/w3c/webpayments-ig/commit/b2c56f1d3190aa9941971d4e191f28192041672a

> *Choice of Payment Instrument I've 3 comments on this one: -I feel 
> that this use case lack the notion of fees associated iwth payment 
> instruments. There is a growing number of sites offering discount if 
> you use specific payment instruments. in the same way, the Payment 
> agent may want to show payment instruments that are not supported by 
> the client but offer better deals?

I have added an example and requirements that highlight this possibility:

https://github.com/w3c/webpayments-ig/commit/1e637c3902bc47cbe7b9a3d79e220bf9e8adf65a

> -There might also be other rewards (points etc) attached to specific
>  instruments that should be considered?

Hopefully the example above covers that. Loyalty points and rewards
aren't specifically mentioned, but we may want to point that out
specifically. Do you think the current text is enough?

> -The way the case is written, i understand (perhaps wrongly) that 
> payment instruments are exclusive (you choose one). Should we 
> consider the use of multiple instruments to complete a transaction, 
> or should that be part of another case? if it is part of another UC 
> (which i think is preferable to keep things simple) we should
> clearly state this.

We haven't started talking about exactly how these items would be
implemented, but I expect that many of the cases that people feel are
going to be implemented using "multiple payment instruments" are
actually combinations of a variety of credentials + a single payment
instrument.

For example, coupons, loyalty cards, discount cards, etc. are all types
of credentials. How the money is actually moved is a part of a payment
instrument.

I've put an issue in the document to highlight that we need to have
deeper discussion on this item.

https://github.com/w3c/webpayments-ig/commit/b2df60dfaebe6445682d0aa6684a1255619ebf36

> *push-based payments I'm a bit puzzled here. I thought that 
> push-based payment was the specific case of the user instructing his 
> own payment processors to pay a merchant?

It is.

> the example one (customer POV) seems related to a merchant storing 
> customers payment instrument information? i was expecting more the 
> paypal model where the user is redirect to his own processor and 
> instruct it to pay the merchant?

Agreed, I updated the example to make it a bit more clear.

> The example two is token-based payment isn't it?

I think I understand what David was saying in the example, but it's
fairly easy to confuse it w/ a tokenized credit card payment. I think
what David was saying was that the payment processor holds a tokenized
credit card (placing even the payment processor out of PCI scope, so in
this case both the merchant and the payment processor are not in PCI
scope).

> I was expecting to have examples that would cover -paypal model
> (i.e. a 3-points architecture)

I updated the last example to be more explicit about it being the PayPal
model.

> -direct deposit model (i.e. a 4-point architecture where the suer 
> instruct his bank to transfer money directly to merchant bank)

I added another POV for the 4-corner model.

Here are the changes based on your input above:

https://github.com/w3c/webpayments-ig/commit/cb01cfceb4b1da0cf1a727c2967b51407a5a5401

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Monday, 19 January 2015 01:39:56 UTC