Re: [use cases] comments on fpwd

Hi Manu,

Ps: let me start with a ps, could-you link to fpwd from the wiki? 
because it tools me a while to find the uri back.

> 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?

right. i mean you select first an instrument that is either push-based, 
token-based, etc.

> 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.

+1 on this, I feel indeed that a meta-use-case is inappropriate. so you 
can remove the issue 1.

> 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?

Well that's one option. The other option is to make this case simpler. 
It will focus only on payment transaction description, and digital 
receipts (including signature as you put)?

> 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).
that's great.


>> *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:

thanks that's clarify.

>> -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?

yes. perhaps adding coupons explicitly may help too.

> 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.

I'm not sure i understand this? the point i'm making is how can i split 
a payment over multiple instruments like we do in the real world: i 
arrive at the market's cashier, the guy give me the bills, i give my 
coupons, my loyalty card and telling him to use the amount on it, and 
finally pay the rest with my credit card. sometime i pay half in cash 
half in cc.
for easiness, I feel that this case should perhaps put as another 
use-case, and we explicitly say here that we are only considering the 
seleciotn of one payment instrument to pay the whole bill. wdyt?

> 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 don't understand this? a loyalty card for me is both a credential, but 
also a payment instrument. I can buy an airline ticket with my loyalty 
points, and the corresponding value is moved out of my account no?
In the same way, coupons is for me a way to pay part of a bill, so I'm 
not sure i understand the difference with a credit card?

or arre you suggesting that we treat differently instrument managing 
real currency, and others?


>> 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.

i think this is very clear now.

>> 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).

could-you detail for me what being in the PCI scope or not means ?

otherwise the examples are great from my POV now.

cheers
steph


-- 
Stephane Boyera        stephane@w3.org
W3C                +33 (0) 6 73 84 87 27
BP 93
F-06902 Sophia Antipolis Cedex,
France

Received on Monday, 19 January 2015 09:47:10 UTC