Re: Scalability of PaymentHandler-based Systems

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
>

Received on Wednesday, 29 April 2020 06:28:37 UTC