Advisory Committee Review of Payment Request API and Payment Method Identifiers

Abstract

The W3C Process (in section 6.3.3. Advancement on the Recommendation Track) states that a Working Group must "provide public documentation of any Formal Objections." The Director received two Formal Objections during Member review of Payment Request API and Payment Method Identifiers. This document is the public record of those Formal Objections. It is also a public record of other comments and the Working Group's responses.

Status of this Document

Note: In September 2022, this document was updated to include information provided to the Council that reviewed one Formal Objection and the Director Decision.

This document has been published as part of the work of the Web Payments Working Group.

On 7 February 2022, the Web Payments Working Group chairs announced a decision to support the language in this document in a transition request to Recommendation.

Those with W3C Member access can review the original review comments.

Organization of this Document

Formal Objections about Payment Request API

Note: This section has been superseded; see the Appendix on the Council Report and the Director Decision.

Criteo

Criteo strongly believes in the goal of the Payment Request API for web clients to facilitate commercial transactions among people, merchants, payment processors and payment providers. Criteo raises a Formal Objection to specific language in the current Proposed Recommendation of the Payment Request API that exceeds this scope and, if not addressed, would open the door to the W3C endorsing a standard whose current language could justify disintermediating ecommerce sites from their customers, as well as enable a browser vendor to put its own interests ahead of users’. We believe such an outcome would contradict W3C’s core mission of promoting interoperability and equal access for all.

This disintermediation concern is called out multiple times during the review (indicated by Notes below).

Criteo supported the following changes to the document to address their concern:

  • Add in the Status section: “Participants MUST ensure that their conduct does not violate antitrust and competition laws and regulations per the W3C Antitrust and Competition Guidance. »
  • Add an informative note directly above Example 7 in the spec text explicitly noting that the algorithm has the potential to be used in an anti-competitive way.
  • Include an informative "considerations" section such as:

    Competition Considerations

    This section is informative.

    This API involves functionality to identify registered payment handlers that match a payee's accepted payment methods and to present those payment handlers to the user. When implementing this functionality, it is important for implementers to comply with applicable antitrust or competition laws and regulations. In particular, implementers should note this when implementing steps 6, 12, and 18 of the show() method.

Regarding the disintermediation concern, the Web Payments Working Group operates under the W3C Antitrust and Competition Guidance, which states that "W3C does not play any role in the competitive decisions of W3C participants [...]” The guidance also states "It is each participant’s responsibility to obtain appropriate legal counsel regarding their conduct in W3C and to comply with applicable antitrust or competition laws and regulations.” Implementers have similar compliance obligations and similar responsibility to obtain their own legal counsel. We believe it is unnecessary to include statements in the specification about these obligations, and impractical to track the possible variation across jurisdictions. We request that the Director permit the specification to advance without including guidance related to disintermediation.

Users must have control over the payment methods of their choice. The order of constituencies ensures the interest of authors, and sites receiving payment, outweigh those of implementors in determining which payment methods they support not only in general but for specific commercial transactions.

The wonderful innovation across the web depends upon both modularity and interoperability. The current language in this proposed standard does not prevent implementors from interfering with both user (payer) and digital property (payee) choice of which payment methods they both agree upon.

The issues and clarifications listed below identify specific text that can be modified to address the risks we have highlighted.

Clarifying the user agent MUST prioritize user’s preferences

The current specification states that user agent “should” (rather than “must”) display user’s preferred payment provider.

“The user agent SHOULD prioritize the user's preference when presenting payment methods.”

To prevent risks associated with user agents relying on other considerations beyond the user’s preference and supported methods by that site when presenting the payment preferences, the specification would be strengthened by making it more explicit that the user agent is a facilitator to the commercial exchange between the user (payer) and the digital property (payee) they are trying to pay.

See disintermediation concern.

The current proposal RECOMMENDS that the show() method sites rely upon to send to the user the array of supported payment methods ought to be matched against the user’s pre-registered payment methods according to a “last one wins” approach. This has two issues.

First, it requires people to pre-register new payment methods outside of the current transaction, which might inhibit the adoption of new payment methods. We do not see how the current specification enables merchants to propose not-yet registered payment methods that are supported by the merchant. It is likely many people would choose not to add every payment method for which they are eligible to every web client they rely on, especially if they use different browsers or different devices.

After discussion with the reviewer, the Editors added an informative note (pull request 978) to the specification explaining that payment handler registration mechanisms are defined outside the API (and cited Payment Handler API as one example).

Second, and more importantly, automating the match between the payer and the payee should not eliminate the user’s choice. For example, certain payment providers offer different discounts for different types of transactions (e.g., higher discounts to food than gas or travel than office supplies or vice versa). A user ought to be able to choose which payment method they prefer when initiating payment, especially when interacting with merchants that offer multiple product categories (e.g., a big box warehouse store that sells food, gas, and office supplies or an establishment that sells both food and ).

The Working Group resolved this concern through discussion about the functionality of the API. In essence, the "last one wins" guidance tells matching payment handlers how the merchant would display the same information on their own site. The browser implementation of Payment Request does not reduce user access to information provided by the merchant to matching payment handlers. How the payment handlers use the merchant-provided hints is out of scope of this API.

Clarifying the user agent is a data processor rather controller over the data exchange

The current specification exceeds the scope of “facilitating” user payments to “disintermediating” the exchange by changing the verb in the proposal relating to the user agent to “act as intermediary.” The browser should be a facilitator not an intermediary. Similar to the risks above, user agents should not alter the list of payment methods beyond what a user prefers due to “other considerations.”

“As part of show(), the user agent typically displays a list of matching payment handlers that satisfy the payment methods accepted by the merchant and other conditions. Matching can take into account payment method information provided as input to the API, information provided by the payment method owner, the payment handlers registered by the user, user preferences, and other considerations.“

The Working Group resolved this concern by removing the quoted informative paragraph (pull request 978)

While describing the user experience associated with the show() method is beyond the proposal scope, we believe the W3C should not propose standards that position user agents to act as independent gatekeepers toward the supported list of payment methods on which both users and digital properties agree. For example, the current specification authorizes user agents to filter the list of payment providers that ought to be directly controlled by the user and the digital property they are trying to pay.

“In addition, the user agent can limit the rate at which a page can call show().”

Additional examples of potential problematic behavior would be:

  1. consistently ranking a rival payment provider or processor at the bottom of the list,
  2. withholding disclosure of payment providers or processors that do not pay an app-store-like facilitation fee,
  3. restricting the list of payment providers or payment processors due to other internal business priorities.

None of these behaviors are part of the W3C’s goals of neutral standards that do not impact competition in any way.

See disintermediation concern.

Removing data filtering from necessary category disclosure for a user’s chosen payment provider to evaluate the transaction

The current proposal states that user agents MUST NOT disclose sensitive commercial information to unintended recipients beyond those required to effect the exchange of value between the user (payer) and a particular recipient (payee).

“The user agent MUST NOT share the values of the displayItems member or additionalDisplayItems member with a third-party payment handler without user consent.”

The proposal would be strengthened by ensuring that it supports the payment providers that require the type of item being purchased displayed. In some cases, payment handlers have a legal obligation of reviewing goods or services being purchased before processing the transaction. For example, “tickets restaurant” is a French payment method. An employer can credit euro amounts on its employees' ticket restaurant accounts, in a partially tax-exempt way. Those ticket restaurant accounts can then be used to pay for food groceries in stores, but not for non-food items. Whenever ticket restaurant is used as a payment method, the payment handler MUST ensure that the items paid for are food groceries only. Thus, if a user is checking out at an online store, only certain categories of items would be eligible for that payment method rather than other items also sold by that same store.

The Working Group resolved this concern by pointing out that these API members are available but not required to be used. A merchant may pass data critical to a payment method to the user's selected payment handler via private data.

Clarifying the user agent is a third-party to the data exchange

Criteo understands the concerns about third-parties repurposing the data of the transaction for processing not disclosed to the user or potentially even the ecommerce payee. The proposal would be strengthened by ensuring that all processing beyond facilitating the commercial transaction are designated as “third-party” processing purposes.

“The user agent MUST NOT share the values of the displayItems member or additionalDisplayItems member with a third-party payment handler without user consent.”

The proposal would ensure it is not discriminating against specific types of B2B vendors, if the language were to state any party, including the user agent (or its parent organization), use the information associated with the transaction for a secondary process, it would be a considered a third-party use. Such a clarification would restrict the B2C user agent from bundling B2B services, such as fraud detection, site analytics or trend analytic to the exclusion of rival B2B services merely from its role in facilitating commerce transactions. To do otherwise would unfairly impact competition by holding the processing of personal data for business uses to a different standard than other third-parties to the user’s interaction with digital properties. Moreover, we need to protect people from being forced to grant increased rights over the payment processing than they desire, without providing user’s choice over this separate “context” from the consumer’s understanding of the established browser scope as a facilitator of their navigation, communication and ecommerce transactions, often through automating form entry.

The Working Group resolved this concern by extending the requirement to all payment handlers (pull request 978). No deployed payment handlers were impacted by this change.

Suggested Solutions

With these concerns in mind, we suggest that the W3C working group update the proposal to address these risks, before the proposal proceeds further towards being an official W3C endorsed standard.

Thank you for your thoughtful consideration of the foreseeable issues we have identified with the proposal in its current state.

51Degrees

Had we been members of the W3C at the time the Web Payments Working Group were chartered in December 2019 we would have requested changes to the charter so that the objective of the group narrowed to the definition of requirements for web primitives that can be used for many use cases and not a single sector’s use cases.

Payment Request API has been designed to address many payments use cases, and the reviewer himself makes a point that underlines the rationale for this API as a Web standard: "Payment and advertising are the two essential drivers of the web economic model."

We agree with the points related to generic handlers made in post titled “The State of W3C Web Payments in 2017” and will not repeat them here.

If W3C charter groups to advance specific sectors such as payment we lose much of the utility of the web. Where do we stop? Payments? Advertising? Insurance? Travel? Education? Medical?

We believe the web should be like "lego" with the minimum number of “brick types” so that may use cases can be solved and innovation can flourish.

At the moment there is no defined scope limit. We advocate for the W3C to adopt clear scope limits for its work.

The Working Group's charter defines the overall scope of the work, and also describes the relationship of Payment Request API and Payment Method Identifiers to other group deliverables.

We ask the Web Payments Group amend their charter to promote generic primitives for payment use cases rather than re-submitting the existing charter should they seek to re-charter in December 2021.

On 19 November 2021, the Director invited Member review of a revised Working Group charter.

As we were not members when the group was charter we must rely now on the Formal Objection process to express these views. For this reason we Formally Object to the proposal and would rather the specification were replaced with one that is generic and solves many use cases.

Because 51Degrees indicated that there were no changes to the specification that would satisfy their concerns, and because the Working Group has previously requested that the Director advance this document to Recommendation (via its Proposed Recommendation transition request), the Working Group recommends that the Director override this Formal Objection.

In addition to the policy issue outline we have the following specific issues with the proposed document as drafted.

  1. Section 1.0 states the “specification describes an API that allows user agents (e.g., browsers) to act as an intermediary between three parties in a transaction”. The majority of the editors past and present are from a single user agent vendor. Given new evidence related to that vendor W3C Director should conduct a more rigorous review of the unintended consequences of this specification before progressing to avoid the specification being used to perpetuate disintermediation associated with the web that detracts from the mission of the W3C or provides user agents unwarranted influence over the web. Payment and advertising are the two essential drivers of the web economic model.

    Here is the list of the six organizations that have provided editors to this specification (in alphabetical order by organization name): Coil, Facebook, Google, Microsoft, Mozilla, W3C. The full list of contributors is even more diverse.

  2. Section 1.1 does not describe a problem to be solved. The first item states “Allow the user agent to act as intermediary between a merchant, user, and payment method provider.” This should be changed to one or more user problems that will be solved. There should also be reference to the author (aka publisher). Implementers needs are third in the list of constituents.

    W3C held a Workshop on Payments in 2014, which led to the creation of the Web Payments Interest Group that developed a set of use cases. Those use cases and Interest Group discussion led to the chartering of the Web Payments Working Group in 2015 with a mission to "make payments easier and more secure on the Web." The goals identified in the group's charter included "better checkout experience," reducing "shopping cart abandonment," and "Easier adoption of payment instrument improvements." The Interest Group and then Working Group have made clear the goals of improving the user experience and streamlining checkout. This is captured in the second bullet of section 1.1, which starts "Enable user agents to streamline the user's payment experience."

Non-Formal Objection Comments about Payment Request API

51Degrees

We observe the following policy inconsistencies between this specification and other proposals being developed in W3C at the moment. They do not form part of the Formal Objection.

Digital Bazaar

Choice: The reviewer does not support publication as a W3C Recommendation for the reasons cited in comments but is not raising a Formal Objection.

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.

The revised Working Group charter sets this expectation about Payment Handler API: "[T]he implementation in Chromium browsers enables experimentation and the Working Group intends to maintain them as Working Drafts. If the implementation landscape changes, the Working Group will revisit the question of advancement to Recommendation and re-charter as needed."

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.

W3C Member

Choice: The reviewer suggests changes, but supports publication as a W3C Recommendation whether or not the changes are adopted.

W3C Member would like to see a section similar to the "Privacy and Security Considerations" section that deals with Environmental and other ethical considerations. This is especially important as the standard will likely be used at some future point to support payments processing utilizing various cryptocurrencies that may have high energy utilization requirements that some users may wish to avoid.

W3C is currently considering this topic (e.g., in the TAG) but at this time there is not yet guidance for Working Groups.

Section 2.1 provides a strong mechanism for supporting multiple payment methods, but may also wish to provide the ability to identify other metadata about the payment method.

The Working Group did not define a generic filtering mechanism in version 1 of this specification. The (deprecated) Basic Card specification did employ a filtering mechanism on two pieces of additional metadata. Presumably the group could develop a filtering mechanism in a future version of the specification.

Due to the fact that requirements associated with environmental considerations have not been consistently standardized across the W3C at this time, we are in favor of publishing as is. We believe issues around environmental and sustainability impacts can be addressed more thoroughly in the future with stronger guidance than currently exists from the W3C. We also believe that better guidance in section 15 around accessibility could be provided. While reliance on existing form handling for accessibility may be helpful in some regards, there should be a normative statement to ensure that at a minimum screen readers and other key items for accessibility are supported by those implementing the specification.
The specification has received accessibility review from the community as part of the W3C Process. The expectation is that implementations will leverage platform accessibility features.

We are also hesitant to make these recommendations more than a suggestion for two reasons, 1) as noted above, there is not clear guidance on ESG statements from W3C, and 2) we have not been actively engaged in the working group to date, and believe that forward progress on useful standards should be promoted as soon as that standard can demonstrably be shown to have value across multiple parties seeking interoperability, as is certainly the case here. To object at this time would not be helpful to the continued growth and adoption of the standard, and while there is still room for improvement, those items that need improvement can be dealt with in future versions.

W3C Member

Choice: The reviewer supports publication as-is.

"Efforts are underway at ISO to account for digital currencies, which may result in an update to the [ISO4217] registry or an entirely new registry. The community expects this will resolve ambiguities that have crept in through the use of non-standard 3-letter codes; for example, does "BTC" refer to Bitcoin or to a future Bhutan currency? At the time of publication, it remains unclear what form this evolution will take, or even the time frame in which the work will be completed."

There should be a section of Ethical, Social and Environmental considerations associated with use use of digital currencies such as Bitcoin, and some guidance should be provided for comparing the total cost to operate digital currency systems such as bitcoin when compared to alternatives.

However, due to the lack of requirements associated with these positions at this time, we are in favor of publishing as is. We believe such issues can be addressed safely and more thoroughly in the future, with better guidance from W3C.

W3C is currently considering this topic (e.g., in the TAG) but at this time there is not yet guidance for Working Groups.

Non-Formal Objection Comments about Payment Method Identifiers

51Degrees

Choice: The reviewer does not support publication as a W3C Recommendation for the reasons cited in comments but is not raising a Formal Objection.

The document appears to be dependent on the former document related to the Payment Request API. As such this document should be reviewed following settling the former document.

Payment Method Identifiers is also used by other specifications such as Payment Handler API.

Digital Bazaar

The reviewer's comments on this specification are the same as for Payment Request API.

W3C Member

Choice: The reviewer supports publication as-is.

"A standardized payment method is a payment method that has undergone standardization at the W3C, and is listed in this registry. At this time there are no standardized payment method identifiers."

There should be 3 "standardized payment method identifiers" and some interoperability tests for them, and one mandatory to implement payment method identifier.

Additionally, there should be an Environmental, Ethical and Social considerations section added to the the Payment Method Specification, and it should consider mechanisms for evaluating the social and environmental costs associated with various payment method schemes. This would ideally be done before attempting to standardize payment method identifiers.

The specification privacy and security section is empty, but this section should provide warnings related to the potential issues associated with standardizing payment method identifiers, such as payment systems where a single legal entity may have full visibility into a ledger, public ledger systems such as Bitcoin, or privacy oriented payment systems such as Monero.

However, due to the lack of requirements associated with these positions at this time, we are in favor of publishing as is. We believe such issues can be addressed safely and more thoroughly in the future, with better guidance from W3C.

Folks familiar with recent formal objections will recognize some commonality here, it's our understanding that all W3C specifications are to be evaluated under equal criteria.

Since payments have the potential to drastically impact the use of crypto currency, which has significant ethical, social and environmental considerations, we feel its important that these specifications speak to these concerns, even if only to point out, that not all payment methods use crypto currencies, and those that do have benefits and risks, and that developers and users should take responsibility for the consequences associated with implementing and using such technologies.

However, we feel it is not appropriate to formally object to the work, since we have not actively participated in it, and we believe that these concerns can be addressed by future revisions of these specifications.

We remain confident that "standardized payment method identifiers" can be developed and demonstrated to be interoperable, and that it is appropriate to publish the Payment Method Identifiers specification first.

Activities to Resolve Formal Objections after AC Review

The following activities took place post-AC Review to seek further consensus:

To summarize the outcomes of these activities:

Appendix: Council Report

In May 2022, the Director requested the creation of a Council to evaluate the Criteo Formal Objection. Related resources:

Appendix: Director Decision

W3C Member 51Degrees raised two Formal Objections to advancing the Payment Request API specification to W3C Recommendation status:

  1. Section 1.0 states the “specification describes an API that allows user agents (e.g., browsers) to act as an intermediary between three parties in a transaction”. The majority of the editors past and present are from a single user agent vendor. Given new evidence related to that vendor W3C Director should conduct a more rigorous review of the unintended consequences of this specification before progressing to avoid the specification being used to perpetuate disintermediation associated with the web that detracts from the mission of the W3C or provides user agents unwarranted influence over the web. Payment and advertising are the two essential drivers of the web economic model.
  2. Section 1.1 does not describe a problem to be solved. The first item states “Allow the user agent to act as intermediary between a merchant, user, and payment method provider.” This should be changed to one or more user problems that will be solved. There should also be reference to the author (aka publisher). Implementers needs are third in the list of constituents.

Regarding the first objection asking for “more rigorous review”, W3C expects and encourages the web community to review all Recommendation Track work and bring specific concerns to the attention of the Working Group and the community, and when possible, with suggested changes to address those concerns. The “wide review” requirement of the W3C Process is the means by which W3C solicits such input.

This objection cites the affiliations of the editors as the basis for the concern. The editors of W3C specifications are selected by the Working Group and are responsible for accurately reflecting the consensus of the entire Group, regardless of their individual affiliations. The objector’s comment has been a matter of public record since October 2021, giving the community opportunity to identify specific issues of the sort the objector postulates. As none have as yet been raised the Director overrules this objection.

Regarding the second objection asking that the introduction section “be changed to one or more user problems that will be solved … also reference to the author [and] implementors needs”, though W3C does encourage Working Groups to collect and publish use cases and requirements prior to working on specifications, such Working Group Notes are not a requirement. These are often omitted by a Working Group when its participants feel they have sufficient shared understanding of the problems they intend to address. In the case of the Web Payments Working Group, its charter contains several bullet points that describe use cases at a high level. The W3C Process provides opportunity for the community to propose specific use cases or requirements to the Working Group, especially when a potential omission is identified in the Group’s published Working Drafts.

This objection is to a non-normative portion of the specification and is editorial in nature. The Director overrules this objection.

W3C Member Criteo raised Formal Objections to advancing the Payment Request API specification to W3C Recommendation status. Some were resolved to the satisfaction of the objector. The remaining objections are:

The Director asked the Advisory Board and Technical Architecture Group to act as a Formal Objection Council and make a recommendation on whether or not to sustain this objection.

That combined group recommended that the objection be overruled. Their full report is available. The Director thanks the Council for their careful consideration of the objection and adopts their recommendation to overrule this objection.

Ralph Swick, for Tim Berners-Lee
6 September, 2022