Editor: Ian Jacobs <ij@w3.org>
Visibility: Public.
Status steps:
Formatting note:
<UNRESOLVED>
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.
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.
</UNRESOLVED>
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.
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 ).
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.“
<UNRESOLVED>
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.
</UNRESOLVED>
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.
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.
<UNRESOLVED>
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.
</UNRESOLVED>
The Team contact met several times with Criteo to discuss the Formal Objection with three outcomes:
The Working Group and Criteo did not reach consensus on the disintermediation concern.
On 2022-02-08, Criteo requested (in email to the Team contact) that this document describe the remaining concern as follows:
“Unfortunately, the other issues with the document’s language remain, namely some open-ended language (see excerpts below) that could be used by an implementer to justify preferencing one or several payment solutions for its own commercial interests, exceeding the scope of the working group to facilitate payments between users and merchants. For example, the current language states a user agent could show only its own payment solution “if the user agent wishes” or filter rivals’ solutions “at its discretion.” We believe the specification should be updated to explicitly address these uncharitable readings.
“We hope the Director ensures that specifications do not leave open user agents to use W3C to justify interference with user and merchant communication in ways that would restrict competition, especially silently and without user or merchant notification.”
Excerpts (emphasis added):
In late 2021 Criteo proposed (to the Team contact, who included them in Working Group documentation) the following changes to the document to satisfy their concern:
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.
Brief discussion with the Working Group on 2021-12-09 did not garner support for the proposal.
On 2022-01-04 the Chairs announced a Call for Consensus to advance to Recommendation. Six participants indicated support for the proposal to advance. Criteo (as a Working Group participant) reiterated (the still unresolved element of) the objection raised during the AC Review. Through the Call for Consensus, the Chairs recorded a decision to include the text below in the documentation of the group’s response to this element of the Formal Objection:
“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. The Working Group believes it is unnecessary to include statements in the specification about these obligations, and impractical to track the possible variation across jurisdictions. The Working Group requests that the Director permit the specification to advance without including guidance related to disintermediation.“
In response to this Decision, Criteo requested an opportunity to discuss the remaining concern with the Working Group; see the 13 January 2022 meeting minutes of that discussion and follow-up thread. In that discussion, Criteo proposed another change to satisfy their concern:
“As discussed, we think that there is some open-ended language in the Payment Request API proposal that could be used by an implementer to justify preferencing one or several payment solutions, for its own interests, and we think this should be addressed.
“To address this concern, we’ve proposed to add references to competition laws and/or the W3C Antitrust and Competition Guidance. During the call, we suggested an alternate approach which would be to bound the open-ended language by further limiting it only to the “protection of user security or privacy”.
“We are open to both possibilities or any other suggestion that could address this concern.
“We wanted to also clarify for those not on the call some of the misunderstandings of the points we raised: We do not mean for implementers of the spec to become experts in regional laws, nor for the W3C to police whether the content of the spec or the implementers violate these laws. Instead, our concern is focused on ensuring the spec itself abides by existing W3C policies.
“We’ll be raising this concern in the Jan 14 Call for Consensus, but we hope that a common agreement can be found in advance. If not, we hope today’s conversation or a summary of the three clarifications above can be sent to help in the broader W3C review process.”
The Team contact replied with observations based on the discussion at the 13 January WPWG meeting:
“I heard the following on today’s call:
* Language such as “protection of user security or privacy” would address your concern, but would likely be over-constraining from an implementer perspective.
* Language such as “protection of the user” (or similar) might be acceptable from an implementer perspective, but I think I heard would not satisfy Criteo’s concerns.
“Do you have any suggestions for verbiage that is “in between” those two?
“I am dubious that we will get there by growing the enumeration, for example: "for reasons of security, privacy, performance, resource consumption, …”
“I did not hear much support on the call to address the concern with references in the specification to anti-competitive behaviors or antitrust guidance.”
Criteo responded:
“Language such as “protection of user, for reasons such as security or privacy, but not self-preferencing business interests of the implementer." would be ok for us. It tackles our competition concern and does not include an exhaustive list of dos/donts.”
On 14 January Criteo restated their suggestions:
Based on 13 January discussion, on 18 January the Chairs opened a 10-day window for proposals (including the "for security and privacy reasons” enumeration approach), and described a process for next steps.
No new proposals were sent to the Working Group. On 4 February, Google indicated lack of support for an enumeration approach to resolving the remaining element of the formal objection.
Following these efforts, the Chairs concluded that the group would be unlikely to achieve greater consensus. Therefore, on 7 February 2022, the Chairs announced a decision to request to advance Payment Request and Payment Method Identifiers to Recommendation over the remaining element of the Formal Objection; see the transition request, which includes a link to the language adopted by the Working Group.
Following a call for consensus, on 2021-12-09 the Chairs announced a Working Group decision to make changes for three of the four elements of Criteo’s Formal Objection. These changes were non-substantive: they were either editorial in nature or had no impact on deployed solutions.
Regarding: “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.”
Change: 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).
Regarding: ‘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.’
Change: Removal from the section “How user agents match payment handlers” of the following informative paragraph (pull request 978): “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.”
Regarding: “The proposal would be strengthened by ensuring that all processing beyond facilitating the commercial transaction are designated as “third-party” processing purposes.”
Change: The requirement not to share values of displayItems or additionalDisplayItems was extended to all payment handlers (pull request 978). No deployed payment handlers were impacted by this change.
Regarding: “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 ). “
Clarification: 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.
Regarding the section: “Removing data filtering from necessary category disclosure for a user’s chosen payment provider to evaluate the transaction”
Clarification: “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.“