RE: We

<snip>
As Nick S points out I don't think a mechanism for the payee to discover the payer's supported instruments will work due to privacy issues.
Why ? we could imagine that the payee provide all the supported payment instruments and then the answer could be a by default instrument or a choose list which is the intersection between payee’s list and payer’s list. To cope with privacy issue: 1) the possibility of the payer to be warned when this request occurs 2) no request upfront but only when the user is agree to buy.

</snip>

I had something similar in mind as Cyril. I don’t think the UA need return all supported methods but in effect what happens today is that a user selects a payment method and steps into that payment method but can step back out again if it looks more expensive (for example) than the original cost. I’m trying to anticipate that negotiation. I’m not sure the privacy issues are that significant – we’re not exposing the payment credentials, but simply exploring what each party is prepared to use. If that’s problematic then I guess you have to offer a single instrument as being available, then the payee responds with a (possibly) recalculated currency/value pair which can then be accepted or rejected. This still allows for sequential fishing but I don’t really see a way around that.

As Zach points out, it would be unusual for a merchant to offer hundreds of payment methods but many offer tens. The UX isn’t always very lovely as a result – which is why I’m keen that we cover this off. It is in particular the combination of currency and instrument that makes this challenging.

<snip2>
Perhaps all that is required here is inclusion of the PSPs in the diagrams and descriptions for context with a note that the communication with these is not in scope for standardisation.
</snip2>

I certainly think there is value in this – the point I was trying to make (perhaps badly) is that push or pull payments may both actually be routed initially via the merchant’s (payee’s) processor/provider even if subsequently the communication is directly between the payer and their provider. So putting these actors into the diagrams is useful.

Thanks
Nick
--
Nick Telford-Reed
e: nick.telford-reed@worldpay.com<mailto:nick.telford-reed@worldpay.com> | m: +447799473854 | t: +44 203 664 5069

From: VIGNET cyril [mailto:Cyril.VIGNET@bpce.fr]
Sent: 25 September 2015 17:08
To: Adrian Hope-Bailie; Nick Shearer
Cc: Telford-Reed, Nick; public-webpayments-ig@w3.org; VERONNEAU Eric
Subject: RE: We

I think Zach is correct here. The relationship between either payer or payee and their respective payment service providers is out of scope of what the WG will standardise but that is not to say they are not critical parts of the ecosystem. This is mostly just an issue of perception.
I am not sure that putting out the providers (merchant’s provider and client’s provider) is a good idea. In order to ensure the security of the flows, those 2 providers should be involved … and if they are not, why are we using the term “payment” in the name of the WG.

As Nick pints out I don't think a mechanism for the payee to discover the payer's supported instruments will work due to privacy issues.
Why ? we could imagine that the payee provide all the supported payment instruments and then the answer could be a by default instrument or a choose list which is the intersection between payee’s list and payer’s list. To cope with privacy issue: 1) the possibility of the payer to be warned when this request occurs 2) no request upfront but only when the user is agree to buy.

Perhaps all that is required here is inclusion of the PSPs in the diagrams and descriptions for context with a note that the communication with these is not in scope for standardisation

Yes a diagram should be great … but I had rather with both PSP.

Regards

Cyril

De : Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
Envoyé : vendredi 25 septembre 2015 17:51
À : Nick Shearer
Cc : Telford-Reed, Nick; public-webpayments-ig@w3.org<mailto:public-webpayments-ig@w3.org>
Objet : Re: We

.

On 25 September 2015 at 12:40, Nick Shearer <nshearer@apple.com<mailto:nshearer@apple.com>> wrote:

On Sep 25, 2015, at 5:52 AM, Telford-Reed, Nick <Nick.Telford-Reed@worldpay.com<mailto: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.

If you’re proposing a discovery API where a merchant can query a user’s wallet up-front before starting a payment (which I think is what you’re saying) then you’re also going to need to propose a privacy model that prevents payees going on fishing expeditions.

There would be nothing to a stop a payee initiating a discovery process then baling out of the payment, leaving them with the contents of a user’s wallet. So any discovery proposal really does have to have a privacy strategy to back it up.


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<mailto:nick.telford-reed@worldpay.com> | m: +447799473854<tel:%2B447799473854> | t: +44 203 664 5069<tel:%2B44%20203%20664%205069>

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<mailto: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<mailto:ij@w3.org>> wrote:

> On Sep 23, 2015, at 10:37 AM, Evgeny Vinogradov <jonny@yamoney.ru<mailto: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<mailto:ij@w3.org>>      http://www.w3.org/People/Jacobs

Tel:                       +1 718 260 9447<tel:%2B1%20718%20260%209447>





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<http://www.dnb.nl/>. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.





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.