Re: DECISION: Regarding Call for Consensus to publish Payment Request API as a Proposed Recommendation; please review one change by 1 February.

Marcos,

AFAIK, a primary goal for the WG was to create a payment API that permitted writing payment applications in "pure" Web technology.

However, the companion API that enables this functionality (PaymentHandler), is currently only available in Chromium.

What is worse is that the WG have not spent any cycles verifying that you actually can build payment applications that are competitive with the mobile native payment apps that currently "own" the market.  From WG minutes and GitHub I have rather noted some pretty thorny issues which after all these years should have been resolved, alternatively put the effort on ice.

Anders

On 2021-01-28 07:21, Marcos Caceres wrote:
> 
> 
>> On 28 Jan 2021, at 9:46 am, Ian Jacobs <ij@w3.org> wrote:
>>
>>> On Jan 27, 2021, at 3:24 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:
>>> Two implementations do exist from web kit and chromium, but these only serve the purposes of the duopoly of Apple and Chromium. Adrian has commented that "Web-based payment handler using open interfaces that can be implemented by anyone else." Which is technically true, but meaningless given the control of the two implementations on the marketplace. I have been informed by members of the WG that implementations for Apple and Google have been accepted as two distinct implementations.
>>
>> I believe that today the Webkit project and the Blink project are independent, both in code base and governance:
>>    https://webkit.org/
>>    https://www.chromium.org/blink
>>
>> I welcome input from others on this point.
> 
> I can attest that they are completely separate implementations and share no code. The fact that the PR API can drive completely different native payment handlers (Apple Pay and Google Pay) underscores both the interoperable nature of the API _and_ the code independence.
>   
>> As an aside, the Firefox Platform Status [1] lists Payment Request as “in development” although I don’t believe much new development is happening at this time (but I haven’t verified lately).
> 
> As maintainer of the Gecko implementation, and one of the Editors of the specification, the specification is fit for purpose in as far as it provides details for how to create an interoperable implementation of the PR API (in Gecko's case, backed by "Basic Card").  Although Mozilla chose not to ship the API, it doesn't mean that the API cannot be implemented in an interoperable manner. Implementation experience showed the exact opposite: we had three highly interoperable implementations, even if the Gecko one never shipped. Further, Firefox's implementation was fully interoperable with Chrome's Basic Card implementation.
> 
>>> II Fairness: I have been denied access to the group to make my opinions known.
>>
>> Although you are not a formal participant in the group, as this email shows (as well as our commitment to carry it forward to the Director),
>> you have not been denied access to the group.
> 
> I agree this is surprising. Everyone has been free to contribute to the specification development process via GitHub. We've received a wide range of input from folks from all over the world - ranging from industry to academia, and everything in between - and have never prevented anyone from participating by filing issues or sending pull requests?
> 
> 
> 
>

Received on Thursday, 28 January 2021 17:45:15 UTC