Re: [use cases] comments on fpwd

Stephane:
I think we have the same idea of push payment but evidently I wrote it wrong. There is no holding of payer information by the merchant.
Best regards, David

Ars longa, vita brevis...

On Jan 16, 2015, at 12:22 AM, "Stephane Boyera" <boyera@w3.org<mailto:boyera@w3.org>> wrote:

Hi,

I have just reviewed the use-cases that are in the FPWD (https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html ) and have a few comments

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

*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?
-There might also be other rewards (points etc) attached to specific instruments that should be considered?
-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.

*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?
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?
The example two is token-based payment isn't it?
I was expecting to have examples that would cover
-paypal model (i.e. a 3-points architecture)
-direct deposit model (i.e. a 4-point architecture where the suer instruct his bank to transfer money directly to merchant bank)

or did i miss something?

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

Ars longa, vita brevis...

On Jan 16, 2015, at 12:22 AM, "Stephane Boyera" <boyera@w3.org<mailto:boyera@w3.org>> wrote:

Hi,

I have just reviewed the use-cases that are in the FPWD (https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html ) and have a few comments

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

*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?
-There might also be other rewards (points etc) attached to specific instruments that should be considered?
-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.

*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?
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?
The example two is token-based payment isn't it?
I was expecting to have examples that would cover
-paypal model (i.e. a 3-points architecture)
-direct deposit model (i.e. a 4-point architecture where the suer instruct his bank to transfer money directly to merchant bank)

or did i miss something?

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

________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

Received on Friday, 16 January 2015 15:33:51 UTC