response to 'Call for Review: Payment Request API and Payment Method Identifiers are W3C Proposed Recommendations'

Please find below Criteo response to the Payment Request API and Payment Method Identifiers call for review.

Lionel
---

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 Criteo by Lionel Basdevant.

Regarding the "Payment Request API" specification, the reviewer  suggests changes, and only supports publication as a Recommendation if the changes are adopted [Formal Objection].


Additional comments about the specification:
   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.

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.“

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.



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.



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.


Answers to this questionnaire can be set and changed at
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F33280%2Fpayments-pr-2021%2F&data=04%7C01%7Cj.koran%40criteo.com%7Ca178e38193c443a9ae6b08d99a166678%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C0%7C637710243323840936%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2xaIgW5lwPRt65OGxxXdvjSh29NhJ0ZydX2qZ60duYM%3D&reserved=0 until 2021-10-28.

 Regards,

 The Automatic WBS Mailer