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

> 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 <http://www.w3.org/2015/03/wpay-usecases.html>

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.

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.

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.

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.

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

Best regards,

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>