Re: Payment App spec implementations

On 03/09/2017 12:25 PM, Adrian Hope-Bailie wrote:
> Assuming that all of the major vendors are going to implement PR API
>  soon what would be the value of the polyfill? Are you suggesting it
>  could add payment apps functionality where that is not available?

Yes, that would be one of the purposes of a polyfill. A secondary
purpose would be the capability to spec out and iterate on new features
before browser implementation happens (which is expensive to do and
takes lots of time to iterate on).

Also, note that implementing the PR API in a browser today still means
that there will be hundreds of millions of browsers that will not have
access to it due to the length of upgrade cycles... which puts people
trying to deploy it into at least one of two situations:

1) Waiting for deployment to get broad enough to deploy (which could
   take years).
2) Writing complicated fallback algorithms which prevents the market
   from experiencing the new technology/flow.

The option always exists to not use the polyfill and take one of the two
approaches above. However, having a polyfill would enable those of us
that want to push out Payment Apps and PaymentRequest to have the
ability to do so while the browser implementations catch up.

At the same time, I don't mean to trivialize the difficulty of writing
the polyfill. There are concerns around security and deployment and
there is no clear answer to polyfilling the native apps portion of
payment app selection... these are issues we'd have to look into further
(and the group may find that a distraction, which is why we'd try to
come up with a solution before presenting to the group).

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Rebalancing How the Web is Built
http://manu.sporny.org/2016/rebalancing/

Received on Thursday, 9 March 2017 22:33:13 UTC