Re: Scalability of PaymentHandler-based Systems

Hi Anders,

Responses inline below:

On Sat, 25 Apr 2020 at 07:07, Anders Rundgren <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
>
>