Re: We

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).

This email addresses the action we had to deal with this issue:


*ACTION-159: Work with zach on payment completion language for charter*
http://www.w3.org/Payments/IG/track/actions/159

To clarify the options that were on the table:


*2 phases - As stated in the original charter and shown in the diagrams*
1) A request to initiate a payment from the payee containing terms and
payment options is passed to the browser API.
2) "Discovery" - some component, in the browser or otherwise, with
knowledge of the payment instruments that the payer has
registered/installed receives the payment initiation request and determines
which of the payer's payment instruments are applicable for this payment.
3) The user is prompted to select from the list of payment instruments.
4) A response to the payment initiation request is returned to the payee
website.

5a - Debit Pull) If the selected instrument is a "debit pull" type
instrument the payee begins processing the payment (probably by passing
some credentials or other data that was returned in the payment initiation
response to a payment processor).
6a - Payment Notification) Once the payee has processed the payment they
send a notification to the payer via the API that the payment is complete.
(This could be optional as the payment scheme may already do this out of
band)

5b - Credit Push) If the selected instrument is a "credit push" type
instrument the payee passes a request to complete/execute/process the
payment to the payer via the API.
6b) The payer begins processing the payment.
7b) Once the payer has processed the payment they return a response to the
payment completion request containing a proof of payment or payment
reference for the payee to verify that the payment has been completed.


*1 phase - As stated in both the Google and Digital Bazaar proposals and
the more recent versions of the charter*
1) A payment request from the payee containing terms and payment options is
passed to the browser API.
2) "Discovery" - some component, in the browser or otherwise, with
knowledge of the payment instruments that the payer has
registered/installed receives the payment request and determines which of
the payer's payment instruments are applicable for this payment.
3) The user is prompted to select from the list of payment instruments.

4a - Credit Push) If the selected instrument is a "credit push" type
instrument the payer begins processing the payment.
5a) Once the payer has processed the payment they return a response to the
payment request containing a proof of payment or payment reference for the
payee to verify that the payment has been completed.

4a - Debit Pull) If the selected instrument is a "debit pull" type
instrument the payer returns the payment response containing the necessary
data for the payee to begin processing the payment.
4b) The payee processes the payment.

*Discussion points*

   1. The reasoning behind the 2 phase approach (option 1) is giving the
   payee more control over the flow.
   i.e. The payee knows when submitting the payment initiation request that
   the payment will not be completed before they have a chance to perform any
   additional steps they may wish to perform based upon the payer's choice of
   payment instrument.

   2. Possible use cases that justify a 2 phase flow may relate to
   additional data that the payee must capture before processing the payment
   or the need to defer the actual payment for some reason. These should
   probably be discussed and clarified in the Use Cases document before the WG
   starts it's work.

   3. The primary motivation for a single phase flow is UX. The context
   switch from payee website to digital wallet/instrument, and associated
   change of UI focus, should not be done more than once unless absolutely
   necessary.

   4. There was some confusion about what the "Payment Completion Request"
   means. (@Evgeny: Your third point seems to indicate you also misunderstood
   the intent here in the original charter).

   The payment is not completed in this step nor is the payee bypassing the
   payer and somehow requesting completion of a "credit push" payment from the
   payer's payment service provider.

   Rather, in the case of a credit push payment, this is a request *from
   the payee to the payer* to complete the payment. It is expected that
   when the payer gets this request they will send an appropriate completion
   request to their payment service provider or similar.

   5. The Google proposal makes use of an event-based pattern to allow the
   payee to respond to triggers from the wallet/payment instrument as the
   payer is selecting their payment instrument and/or capturing additional
   data. This would require that the payee respond to these events within some
   timeout to not adversely affect the UX but still allow them to execute new
   logic such as prompting for additional data if the payer's actions trigger
   this. This is demonstrated in the proposal through the capture of shipping
   details.



*Conclusions*
In defining a flow such as this there is always a need to compromise
between UX and flexibility. Breaking any data capture process into multiple
steps will make the flow of that process more flexible as the process can
adapt to input at each step however that flexibility comes at the cost of
increasingly poor UX and, in the case of payments, an increased chance that
the payer will abandon the payment.

While Google still feel strongly that jeopardising the UX by having 2
phases is a bad idea they acknowledge that there may be cases where this is
required and are open to a compromise that can be discussed further when
the WG starts its work and do a more thorough job of evaluating the need
for a second phase and the effect of adding it.

Using an event-based pattern versus a multi-phase request/response pattern
was considered detail that can be determined by the WG.


*Proposal*
The proposal is to use a single phase flow but to allow the payee to
explicitly request that they wish to "defer payment" (possibly limited to a
specific set of payment instruments).

This indicator would be passed in the payment request by the payee. If the
payer selects a credit push instrument and the "defer payment" flag is set
then the payer will not process the payment but will proceed as per the 2
phase flow above and simply return a response to the payee indicating which
instrument they have selected.

Note that if this API implements the event-based pattern suggested by
Google this may simply mean that a "paymentInstrumentSelected" event, or
similar, will be raised.

Also note that the concept of a "payment initiation request" has been
dropped in favour of simply using a "payment request".

Ian has updated the new proposed charter to reflect this proposal, comments
welcome:
http://w3c.github.io/webpayments-ig/latest/charters/payments-wg-charter.html

On 23 September 2015 at 18:55, Ian Jacobs <ij@w3.org> wrote:

>
> > On Sep 23, 2015, at 10:37 AM, Evgeny Vinogradov <jonny@yamoney.ru>
> wrote:
> >
> > Dear Interest Group,
> >
> > I’ve few comments to share about the Web Payments Charter FAQ.
>
> Thank you, Evgeny.
>
> (As a side note, I expect the FAQ will need to be updated as we update the
> charter itself. For example, I think the diagram needs
> to be adjusted in light of conversations that took place earlier this
> week.)
>
> Some notes inline.
>
> Ian
>
> > 1. It is stated there that moving from 2-factor authentification
> standard to 3 Factor in one of the challenges. But do we really need that
> challenge? Probably we should replace it with something like "the lightest
> authentication possible for the relevant level of security". There are
> cases where we need to have the strongest authentication possible (e.g.
> cross-border payment of large sums), but at the same time there are cases
> when we use very light authentication - for example a small amount for a
> service that was paid by same person many times in the recent past.
>
> I'‘m fine to make a change. What about this alternative:
>
>  “Availability of different authentication methods depending on the
> required level of security."
>
> >
> > 2. Second comment is about payment flow scheme (
> https://www.w3.org/Payments/IG/wiki/Web_Payments_WG_Charter_FAQ#What_payment_flows_will_the_standards_support.3F
> ).
> > There is a "Prompt user to: ... Confirm terms" point before "Send
> payment initiation response". However, not all terms can be known at this
> stage since there are other steps which can influence terms (e.g. on the
> side of Payee Web Application) after it. So "Confirm terms" should be moved
> to a position just before "Payments processing" and after Payment
> Initiation Response. Alternatively, another "Confirm contract details" step
> can be added instead, but I think gets too detailed.
>
> I’ll see if Adrian’s available to help update the diagram and take this
> into account.
> (Also, the text before the diagram also needs to be updated.)
> >
> > 3. About credit push payment example. There it is stated “The payee (via
> the Web application) sends a payment completion request to the browser.”
> But it not necessarily the payee who makes this request. In cases like ours
> the payer is the one who sends a payment completion request for a wallet
> services, with the next step being to notify a payee.
>
> I agree we need to review all these examples in light of the discussion
> this week about flow.
>
> Thanks again for the review and stay tuned for edits to align with charter
> changes!
>
> Ian
> --
> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> Tel:                       +1 718 260 9447
>
>
>
>