Re: Scalability of PaymentHandler-based Systems

On 2020-04-29 09:18, Adrian Hope-Bailie wrote:
> Can you suggest which payment providers we should be encouraging to join the WG?

No, I cannot for the simple reason that payment providers rarely participate in open standardization forums like W3C, IETF or Oasis.

The only thing I know for sure (which also is easy to verify), is that the majority of existing payment providers are targeting a wider range of payment scenarios than the Payment WG do.  This affects technology choices and typically make native payment handlers the most logical path.

However, the current solution for native payment handlers is a kludge: https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf
while this one (with respect to PaymentRequest NB), is a blocker: https://github.com/w3c/payment-request/issues/865

If you have any additional questions please send the off-list since it is apparent that this topic is of no interest to the WG members.

Anders

> 
> There are already quite a number in the group but we always welcome wider stakeholder representation
> 
> On Wed, Apr 29, 2020 at 08:28 Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     Since the payment providers are practically absent from the Payment WG activities, the arguments (from both "sides"...) are of little value.  We leave it there.
> 
>     Anders
> 
>     On 2020-04-28 20:00, Adrian Hope-Bailie wrote:
>      > Hi Anders,
>      >
>      > Responses inline below:
>      >
>      > On Sat, 25 Apr 2020 at 07:07, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote:
>      >
>      >     Assume that a bank wants to use W3C's PaymentHandler.  They have two options:
>      >     - Creating a unique payment method
>      >     - Sharing a payment method with other banks
>      >
>      >     Creating a unique payment method may be logical at first sight but makes it difficult for Merchants who need to deal with potentially thousands of different methods.
>      >
>      >
>      > Our expectation is that in this case the banks would standardise on payment methods that correspond to the payment schemes they use.
>      > E.g. SEPA credit transfer and SEPA direct debit have already been explored by SWIFT
>      >
>      >     So the only realistic solution is that banks standardize on a few common payment methods and associated PaymentHandler applications. What is not equally evident is the consequence of that, but as far as I can tell, a user with multiple banks would be forced to select PaymentHandler application from a browser generated list.
>      >
>      >
>      > Yes, unless they have defined a default.
>      > This seems like a perfectly logical flow to me, perhaps I'm missing why this is a problem.
>      >
>      >     In addition, there are no guarantees that PaymentHandler applications having a common method name, actually run the same code.
>      >
>      >
>      > No there is not. Payment Methods define the shape of the request and response data, that's all.
>      > That's enough for interoperability.
>      >
>      >
>      >     The lack of signed/vetted code also adds user-related and infrastructural downsides, as well as constraining features.
>      >
>      >
>      > It would be helpful if you could be more specific about what downsides you envision here.
>      > There is no such thing as vetted code on the Web.
>      >
>      >
>      >     Native payment handlers like Apple Pay and Saturn do not suffer from any of these shortcomings.
>      >
>      >
>      > Sure but they do suffer the downside of being published in app stores that can disable them at will with no recourse or explanation.
>      > That's the difference between building for native platforms controlled by their creators and building for the Web.
>      >
>      > In any case, native payment handlers can be invoked from the web using payment request API so I guess we have all bases covered
>      >
>      >
>      >     thanx,
>      >     Anders
>      >
>

Received on Wednesday, 29 April 2020 08:39:58 UTC