Re: Scalability of PaymentHandler-based Systems

On Wed, 29 Apr 2020 at 10:39, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

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

It's not clear to me what you consider a "payment provider", could you
elaborate?

The fact that they may or may not wish to participate is not really
relevant, we have had great success in the past getting participation from
the industry.
In fact, in most cases where there is a specific company or industry body
that we've been encouraged to get in touch with we've had them join the WG
or at least present to or attend a meeting or two.
If you do in fact believe there are industry participants that should be
engaged in the W3C work please tell us who they are and we'll follow up.


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


That's good, I'd expect that they would. Fortunately for the W3C our scope
is limited to use cases involving the Web so we can keep our work focused.
Participants that have a wider scope would find value in participating in
the W3C work as it pertains to their Web ambitions and then also other work
as it pertains to other use case and channels.


> This affects technology choices and typically make native payment handlers
> the most logical path.
>

For a lot of use cases I agree but many PSPs need to consider a variety of
use cases and channels including the Web in which case considering Web
technologies in their solution mix is important.


>
> However, the current solution for native payment handlers is a kludge:
> https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf


There are a few inaccuracies in that document, such as the assertion that
Web applications don't have access to secure hardware (see WebAuthn).

Be that as it may, the scope of the Payments WG is not to create a generic
Web to native bridge.
For a variety of security and privacy reasons I don't expect that will ever
materialize but who knows.


> while this one (with respect to PaymentRequest NB), is a blocker:
> https://github.com/w3c/payment-request/issues/865


In your opinion, yes. If you read the thread both Marcos and I have
suggested a way in which you could achieve what you want using the existing
technology available.

What you are asking for is to abandon the Payment Handler API (the
interface between the browser and issuer domains) in favour of an API that
goes directly to the mobile device.
That's not in scope for W3C, especially if we have a working model already
using Web APIs.


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

Any discussion that will result in clarity of the WG purpose and scope or
that may encourage wider stakeholder participation is welcome.


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