RE: [use cases] comments on fpwd

Hello all,

Sorry for responding to a rather old mail, but I think we should be aware of a few aspects of  'Payment' with loyalty points:
I'm pretty sure we will have to cope with both cases: coupons which give you a discount, and loyalty points you 'feel like you are paying with' but actually reduce the price. On the other side we may have various instruments - perhaps even loyalty points - which the payment is done through. The difference matters from the process POV (in our demo there is a point where the total gets calculated so you know exactly how much you have to pay - important for transparency, in some places even a legal requirement) but also for taxation reasons! Goods you receive for free or at reduced prices are usually not taxed for - final totals are. Sometimes the value of the goods gets deducted entirely (without taxes in most cases). Different tax types might even require different handling!

For proximity we couldn't but decide to have the highest protocol level taking place on the human-to-human layer. In purely digital transactions we need to make sure we can cope with all possibilities somehow... Perhaps by allowing transactions to be broken down whenever the protocol elements we defined can't express complex situations anymore? In proximity cases this isn't too bad - the cashier can make me pay the first 10$ out of my 20$ total by a prepaid card, the rest in a second transaction by CC. It would just be fine to know that the second 'tap' took place in the context of the same transaction. So: don't start to believe in our ability to put it all into one protocol/ one transaction...

Cheers,
 Jörg

-----Original Message-----
From: Stephane Boyera [mailto:boyera@w3.org] 
Sent: Montag, 19. Januar 2015 10:47
To: Manu Sporny; public-webpayments-ig@w3.org
Subject: 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, 26 January 2015 18:41:23 UTC