- From: Manu Sporny via WBS Mailer <sysbot+wbs@w3.org>
- Date: Fri, 29 Oct 2021 03:45:03 +0000
- To: public-new-work@w3.org
The following answers have been successfully submitted to 'Call for Review: Payment Request API and Payment Method Identifiers are W3C Proposed Recommendations' (Advisory Committee) for Digital Bazaar by Manu Sporny. Regarding the "Payment Request API" specification, the reviewer does not support publication as a W3C Recommendation for the reasons cited in comments but is not raising a Formal Objection. Additional comments about the specification: Digital Bazaar continues to be deeply concerned by this specification and its negative effects on user choice and payment method competition especially as it relates to the browser vendor's own payment businesses. The Payment Request API places the browser vendor in between the user and the merchant, limiting their ability to choose competitive payment methods which might be impacted by the browser vendor's own payment business. We note that the two implementing browser vendors also have payment businesses and digital wallet businesses. We also note that the Payment Handler API, which was intended to provide choice in payment handlers has stopped advancing and further note that the Payment Method Identifiers specification, which provides a registry of payment method handlers, contains ZERO registered payment handlers. These are multiple signals that demonstrate that something is truly wrong with this ecosystem. The three browser vendors supporting or abstaining from this work recently raised formal objections on DID Core for not providing standardized examples of multiple DID Methods. We note that the Payment Request API does not provide standardized examples of multiple payment methods and the "Registry of standardized payment methods" states that "At this time there are no standardized payment method identifiers.". We find formally objecting to the DID Core specification on the grounds of not defining DID Methods, but then NOT formally objecting to the Payment Request API for the same reason... troubling and inconsistent. There are 112 DID Methods registered in the DID ecosystem, which is some sign of user choice... there are zero payment method identifiers, which we identify as a negative signal wrt. user choice in the ecosystem. This situation leaves users at the whims of the payment methods supported by the browser with no ability to use alternate competing payment methods without the explicit support of the browser vendor. This would normally be a Formal Objection, but our involvement in the creation of the Web Payments WG and the early days of the Working Group have shown us that doing so would not be a productive use of everyone's time at this stage in the process. There are good people in the Web Payments WG, that tried hard to make this an open ecosystem, but ultimately failed to accomplish creating a specification that creates a level playing field and instead favors existing payment providers (some more than others). We, Digital Bazaar, tried and failed to help the Web Payments Working Group to create an open, competitive ecosystem. The standardization of the Payment Handler API would have done that, except that it was delayed in the hopes of getting Payment Request out... and then was never completed. The issue tracker shows that substantive work on Payment Handler has slowed to a rate that is not going to result in a REC within the current charter, if ever. There is hope if this work is ever picked up and moved forward, but we see no indication of that happening. Our hope is that our view of the ecosystem is incorrect and we have missed some critical piece of information that allows 1) users to install and use payment handlers that are truly competitive with the browser vendors payment solutions (provided and displayed alongside the browser vendors payment offerings as well as traditional card offerings), 2) payment method creators to provide alternatives to existing established market players, and 3) retailers to suggest new payment handlers to their customers that need not be approved by the browser vendors or established payment networks. There is much more detail available at the following blog posts related to the challenges with how the Web Payments WG got here: http://manu.sporny.org/2016/browser-api-incubation-antipattern/ Answers to this questionnaire can be set and changed at https://www.w3.org/2002/09/wbs/33280/payments-pr-2021/ until 2021-10-28. Regards, The Automatic WBS Mailer
Received on Friday, 29 October 2021 03:45:07 UTC