Re: Scalability of PaymentHandler-based Systems

Can you suggest which payment providers we should be encouraging to join
the WG?

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