Re: [use_cases] Web Payments Use Cases - Organized by Phases

> On Mar 10, 2015, at 12:34 PM, Dave Raggett <dsr@w3.org> wrote:
> 
> 
>> On 10 Mar 2015, at 17:03, Ian Jacobs <ij@w3.org> wrote:
>> 
>> I spent some time recasting the use cases in terms of payment phases [1], resulting in:
>> 
>> Web Payments Use Cases - Organized by Phases
>> http://www.w3.org/2015/03/wpay-usecases.html

Hi Dave,

> 
> I believe that  for the negotiation of payment terms phase, we should distinguish between aspects that the  merchant/payee deals with and those aspects involving the user’s digital wallet. In particular, the merchant will want to query which vouchers, discount coupons and loyalty cards that are held by the user’s digital wallet, and should be applied to this transaction. Note this phase does not update the status of the vouchers, coupons or loyalty cards in case the payment transaction is unsuccessful**.
> 
> In the delivery phase, we need to distinguish between proof of payment (e.g. a credit card slip) and a digital receipt listing the goods purchased, terms & conditions etc. One is provided by the payment instrument, and the other by merchant/payee.  The separation is important to merchants who don’t want to share the details of what was purchased with the payment solution providers.

That seems like a useful distinction to me. I suggest we seek to make that distinction in:

 * The phases description
 * The use cases (seem ok as drafted)
 * The glossary

> One challenge is to avoid updating the vouchers, coupons and loyalty cards until the payment has succeeded. This suggests that we need an API for doing so as part of your delivery phase.  You should amend the description of this phase to clarify this separation of roles.

I have updated the description of “Delivery of Receipt” to remove mention of proof of purchase. Now says:

 <strong>Delivery of Receipt</strong>. Depending on the payment scheme(s) chosen, there are various ways and times that a receipt may be delivered by the Payee.

(I have updated in the original use cases doc as well.)

However, it seems like you would like to include a note somewhere (e.g,. in a use case) about updating the vouchers. Where would you add it and what would you say?

> 
> The negotiation of payment instruments could in principle be combined with the payment processing phase.  A payment request API would pass the details of which kinds of payment are accepted by the payee. The user selects a matching payment instrument, and the payment request is then passed to the chosen payment instrument.
> 
> The initiation of the payment is determined by the payment instrument and would depend on whether this is a refund.

I’ve added a note that initiation is scheme dependent. 

I am not yet sure how to handle refunds in this payment flow (since this is an exception outside the ordinary flow).

> 
> For the use cases, the use experience is pretty important, and hence we need to cover the sequence of steps, e.g. each time the user has to hold her phone to a payment terminal.

Yes: we should list all the steps that are necessary to evoke requirements. 

> 
> ** alternatively they could be updated and reverted if the transaction fails or is aborted. I will take a more careful look at how my local super market handles this!
> 

Thanks!

Ian

> Best regards,
> 
> —
>    Dave Raggett <dsr@w3.org>
> 
> 
> 

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447

Received on Tuesday, 10 March 2015 19:36:07 UTC