Re: Update on Web Payments Working Group [The Web Browser API Incubation Anti-Pattern]

On Thu, Apr 7, 2016 at 12:16 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2016-04-07 07:44, Roger Bass wrote:
> <snip>
>
> However, I would suggest that if broad payments interoperability
>>
> > arises elsewhere (i.e. non-browser use cases) it's plausible that
> > that would carry over to the browser use case too.
>
> Yes, but payment system interoperability is not the #1 problem on Web,
> it is rather Convenience, Security, Privacy, and Decentralization.


I don't disagree. However, as the Internet/Web demonstrated, network
innovations that reach global scale tend to keep expanding exponentially:
both vertically (accelerating the growth of other layers that sit on top),
and horizontally (core and best-in-class edge technologies spreading
outward).

In the Web / Internet of Payments (IoP) context, I would suggest a couple
of hypotheses that follow from this:
a) a broad IoP at the data / process / semantic layer will help to
accelerate adoption other layers (viz Interledger CG for settlement)
b) best-in-class IoP models for edge use cases (i.e. Convenience, Security,
Privacy, Cost) will tend to spread to other use cases

This broader dynamic in (b) will apply, I'm suggesting, at various levels:
for national payment systems (especially those that have lagged), but also
different use cases (e.g. extending from B2B/M2M use cases into
consumer/browser use cases).

I've seen various arguments for "killing" or "excluding" certain payment
methods because of security, cost or other problems (check, CNP). I'd agree
that hidden cross-subsidies can be problematic. That said, I tend to prefer
the idea of building an IoP Framework where any payment model can connect,
initially perhaps at the semantic layer. By providing a more consistent
end-user experience or interface (for machine or human users) that would,
I'd argue, facilitate those users transitioning to "better" payment
methods. That's especially so to the extent the IoP Framework helps to
decouple payer and payee side adoption, reducing some of the
chicken-and-egg hurdles. Such an IoP Framework, would also, I suspect,
heighten the competitive pressures on solution or infrastructure providers
that fail to adapt.



On Thu, Apr 7, 2016 at 12:16 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2016-04-07 07:44, Roger Bass wrote:
> <snip>
>
> However, I would suggest that if broad payments interoperability
>>
> > arises elsewhere (i.e. non-browser use cases) it's plausible that
> > that would carry over to the browser use case too.
>
> Yes, but payment system interoperability is not the #1 problem on Web,
> it is rather Convenience, Security, Privacy, and Decentralization.
>
> Another issue which is seldom mentioned is that payments still are
> dominated
> by (functionality-wise) rather variant local solutions, where the US stick
> out
> as a major laggard:
>
> http://www.pymnts.com/news/faster-payments/2016/the-fastest-path-to-faster-payments-in-the-us/
>
> The US is an equally deficient player when it comes to eID which is why
> things
> like credentials probably won't fly in W3C while already being deployed in
> many
> other countries (albeit in some kind of proprietary format and system).
>
> The solution for the Web (if there is one), is IMO creating open technology
> enabling innovation by "anybody" and wait with interoperability until
> there's
> something worth being interoperable with.
>
> The current CNP (Card Not Present) scheme is an example of a system that
> doesn't
> have any legitimate place in a standard:
> https://w3c.github.io/browser-payment-api/specs/basic-card-payment
>
> Apple Pay is much better and if the other players can't match Apple
> they should maybe consider doing something else :-)
>
> Anders
>