Re: We

Hey Nick -

Thanks for brining these up. I'll give my take, but I'm sure others will
jump in as well.

The first is perhaps a matter of perception but it seems that the flow
> diagrams indicate a marginalisation of the role of the payment
> processor/gateway/acquirer.


I think the processor/gateway/acquirer will continue to play a critical
role in this flow. They are left out of the standard because we are not
trying to standardize the communication flow between a merchant and their
respective processing partner, and as such, don't belong in the flow
diagrams. Certainly in the proposal we put forward the processor is a
critical component. This is why the job of the payment instrument is,
typically, to just send back a blob of data that can be sent off to the
merchant's processing partner. In addition, this is why I took such a
strong issue with the text in the charter being around "payment completion"
or "execution of payment". Both of these are, at least in the case of pull
payments, something that needs to be worked out between the merchant and
their processor and should not be part of the standard (that is to say, I
don't think UAs should be communicating with processors).

The second is more practical – we offer (by way of example) 326 different
> payment methods. Sending across all the possible fields/elements for each
> of those methods in a single payment request message from payee to payer is
> unlikely to be a sensible or performant step.


I would imagine that most merchants that use WorldPay don't support 326
different payment methods. Or do they? If so, could you help give an
example of what this looks like on a merchant's web site? I'd be curious to
explore how this works currently.

Assuming this is something we need to contend with, I think we could use
the event system proposed in our proposal
<http://discourse.wicg.io/t/rfc-proposal-for-new-web-payments-api/1100> to
handle this case. We could emit an "instrumentSelected" event and expose a
few more methods on the returned object to alter the price, currency, etc
given the selected payment instrument. Would that address the use case?

-Zach

On Fri, Sep 25, 2015 at 5:52 AM, Telford-Reed, Nick <
Nick.Telford-Reed@worldpay.com> wrote:

> I have two issues I’d like to raise with both proposals and by extension
> the latest draft of the charter.
>
>
>
> The first is perhaps a matter of perception but it seems that the flow
> diagrams indicate a marginalisation of the role of the payment
> processor/gateway/acquirer. I know the narrative text continues to talk
> about payee-initiated payments, but the diagrams in both proposals don’t
> really show anything flowing back (via the merchant/web application)
> through to the gateway/processor/acquirer etc. I think most stakeholders in
> that community would be concerned at a perceived implication that the UA
> was communicating with a scheme directly (in the case of debit pull). It’s
> worth bearing in mind that many “Alternative payment methods” are also
> managed through the payment partner (sitting behind the payee, or
> merchant), even where those payment instruments are perceived as “push”.
>
>
>
> I think we want to avoid this becoming an arms race between connectivity
> in the payment processor/acquirer/gateway to schemes/instruments and
> connectivity in the user agent to schemes/instruments. In many cases, this
> is because the payment processor/acquirer is also obliged to provide
> AML/KYC style services (in the case of traditional cards, the funds, for
> example, must flow through the acquirer which becomes very difficult to
> reconcile if the payment information didn’t also flow that way) but also
> provides other value add services (around fraud/risk monitoring, data
> analytics and aggregation of settlement)  that also rely on the payment
> information being available.
>
>
>
> The charter now references the use case where aggregation services may
> improve functionality for the payer, but not (it seems to me) the reverse
> use case, where aggregation services are provided to the payee (even though
> this is the dominant extant model)
>
>
>
> The second is more practical – we offer (by way of example) 326 different
> payment methods. Sending across all the possible fields/elements for each
> of those methods in a single payment request message from payee to payer is
> unlikely to be a sensible or performant step. By first discovering the
> available payment method and then managing the payment itself, we can send
> across a very much smaller number of formats/metadata. It is also the case
> that the price might change dependent on the combination of currencies and
> payment instruments because of risk profiles, FX costs and merchant
> surcharging. I don’t think a single phase adequately copes with these
> requirements.
>
>
>
> Tl;dr – the diagrams in particular could be perceived as a significant
> competitive threat to incumbent payment processors/acquirers/gateways and
> the single phase flow doesn’t feel practicable.
>
>
>
> Nick
>
>
>
> --
>
> Nick Telford-Reed
>
> e: nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069
>
>
>
> *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
> *Sent:* 24 September 2015 10:44
> *To:* Ian Jacobs
> *Cc:* Evgeny Vinogradov; public-webpayments-ig@w3.org
> *Subject:* 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.
>
>
>    1. 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
>
>
>
>
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>
>
>