Comments on flow and updated diagram

> On Sep 24, 2015, at 4:43 AM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
> 
> Hi Evgeny, Ian, IG,
> 
> I had a chat with Zach (Google) this week about their proposal (and specifically the fact that they are pushing for a single phase flow).

Hi all,

In thinking about this thread, I have have a few remarks:

 * Our focus at this point should be ensuring that the charter scope reflects what work we want to happen. It should be narrow (to enable
   us to focus) but not too narrow. It would be too narrow, for example, if it did not enable innovation or if it precluded the Working Group
   from adapting reasonably based on more in-depth discussions.

 * It’s great that some detailed discussion has begun (e.g., via Zach’s draft or the Payments CG draft). That discussion can help illuminate
   issues with the charter. However, it’s important to remember that we are not designing the APIs in the Interest Group. The APIs are
   very clearly NOT yet decided. I would like especially that we use the detailed discussion to converge on the charter language.
   (Then, we can work on the APIs themselves in the Working Group.)

 * Adrian refers to “single phase.” I don’t think we’ve defined “1 phase” or “2 phase” but I think I understand what is meant, and I disagree.
   My most recent understanding is this:

    a) There is strong consensus that the first part of our future protocol will involve digital payment instrument selection, mediated by the
        user agent.
    b) In SOME cases, once a user has selected a digital payment instrument, it may be sufficient to advance to payment processing. I believe
        this is the “push” case. (Zach, I believe, has indicated that for usability, if payment can be completed without further interactions by
        the payer, this is a superior user experience. That is probably true, but I don’t think that’s the only use case.

        Thus, in SOME cases, once the payee has requested that the user choose a digital payment instrument, the next
        information the payee would receive is a response that “Payment has completed.” That response would likely include a proof
        of payment.

    c) In OTHER cases, once a user has selected a digital payment instrument, it may be that payment processing does not take place
        until further action is taken by the payee.  Some examples include: “pull” case, as well as “deferred push” case (which Adrian wrote up in
        his email on this thread). In this case, the payee receives a signal that “additional processing is required”.

        At this point, if the processing involves the payee’s payment processor (“pull” case), the payee sends the data received via the
        browser to the payment processor to complete payment. Or, if the digital payment instrument involves payment completion on the
        payer side, then the payee can request payment completion (via the payer’s digital payment instrument, mediated by the
        browser). Once payment has completed, the payee is notified (mediated by the browser).

    d) People have pointed out that when payment is completed on the payee side, there are already mechanisms in place (between payee
        and payment service provider) to signal “payment complete” and therefore we don’t need to deal with that in our APIs. However, when
        payment completion happens on the payer side in this latter case, it seems to me that we may need to send a payment completion
        (via the browser) to the payee’s application. If so, then handling the deferred payer-side payment completion does amount to a
        sort of “phase 2” of the protocol, with a request to complete the (deferred) payment, and a signal that it has completed.

This amounts to saying:

 * In some cases, there would be only one phase (non-deferred push, and maybe other cases but I don’t know them)
 * In others, there are two phases (pull and deferred push). The second phase gives the payee some additional opportunities.

Do others share that understanding?

I mentioned that the diagram needed to be updated, and I have done so:
 http://www.w3.org/2015/09/payflow-20150925.png

It’s not yet in the FAQ because I would like feedback on its accuracy first.

Two other remarks:

 * The diagram does NOT intend to show all possible round trips between payee and payer. For instance, Zach’s explainer [1]
   shows a round trip to get shipping information (as needed). There may be other round trips necessary. The diagram is not
   meant to show the API in detail, but to show the overall expectations. I think the diagram is helpful when talking about the work,
   but I think it’s inevitable at the charter stage that there will be limitations to its usefulness.

 * The revised diagram makes clearer that payment processing is happening SOMEWHERE in the protocol even if the Working Group
    is not dealing with processing directly. Nick, does this help address your concerns?

Ian

[1] https://github.com/WICG/paymentrequest/blob/master/explainer.md
[2] https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Sep/0121.html
--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447