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

> On Mar 11, 2015, at 4:47 AM, Dave Raggett <dsr@w3.org> wrote:
> 
> 
>> On 10 Mar 2015, at 19:36, Ian Jacobs <ij@w3.org> wrote:
>> 
>> 
>>> On Mar 10, 2015, at 12:34 PM, Dave Raggett <dsr@w3.org> wrote:
>> 
>> 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 use cases I already submitted cover this to some extent,
> but I think we need further uses cases to cover more of the details.  I will work on that.

+1. Could we chat about how to integrate them into:
 http://www.w3.org/2015/03/wpay-usecases.html

(Either as micro-narratives or use cases)

>  In the meantime, We should mention in the description of the flow that merchant (payee) and customer (payer) need to address the use of vouchers, coupons and loyalty cards during the negotiation phase as it has a bearing on the amount to be paid, and that any vouchers and coupons used for the transaction should be restored if the transaction fails to complete, and likewise, for updates to loyalty cards that “reward” payers for their custom.

Currently the phase "Negotiation of Payment Terms” includes "Application of Marketing Elements” which intends to cover the use of coupons, etc.

But the document as a whole does not (yet) cover exceptions. (For the phase description that is by design to keep it simple.)

I have added this bullet to the “Assumptions” paragraph to remind us of this, and of your particular use case:

  "Exceptions. This document does not explicitly address various exceptions that might happen such as transactions failing. The architecture will need to take these into account (e.g., if a Payer applies a coupon and the transaction fails, the Payer's coupon would be restored).”

Turning this into a general question:

 * Should the use cases (but not the phase model at the higher level) call out exceptions that need to be addressed in the architecture?
   Or should these first appear in the architecture?


> 
>> 
>>> 
>>> 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).
> 
> My understanding is that a refund is a reverse payment that is linked to a previous transaction.  I would expect merchants to provide customers with a receipt that indicates this, since this will allow the transaction records to be matched.  I assume that the negotiation phase of the flow is simplified since the terms and conditions are set by the linked transaction.  Presumably, any vouchers or coupons used in the original transaction should also be handed back, and likewise for loyalty cards.
> 
> It would be interesting to hear from the experts in the IG for how refunds are handled in today’s systems.

I had included Refunds in the default flow in an early draft. Lauren argued [1] that Refunds don’t fit into the purchase flow easily so I removed it.

We may need more than one flow description for:

 * Refunds (or similar)
 * Peer-to-peer payments

I have raised this on email [2] and on a group call but for the moment I am not hearing a big push (via the use cases) for different flows.
(My prediction is we will.)

Ian

[1] https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0071.html
[2] https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0075.html

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

Received on Wednesday, 11 March 2015 13:06:03 UTC