Is tokenUsageType useful for SRC?

[ianbjacobs]

In the tokenization spec we defined a token usage type input parameter: https://w3c.github.io/webpayments-methods-tokenization/index.html#tokenusagetype-enum

Some feedback we've heard:

• Card-on-file would be a nice-to-have, but not requirement for version 1.
• "Recurring" flag may not be meaningful for tokenizedCard or otherwise. Once card-on-file is created, merchant can use it in context of recurring.

[ianbjacobs]

After reading some documentation by Visa ("Improving Authorization Management for Transactions with Stored Credentials") here are some thoughts. I welcome corrections.

• Visa distinguishes between card-on-file and not-card-on-file use cases. This would mean our payment method does not need to distinguish “recurring” from “installment” from “future transactions” use cases. If this is true for other brands, then we could enable the merchant to pass a boolean through the payment request API, for example “card-on-file.” It could be false by default but the merchant could set it to true for a variety of COF use cases.
• When the payment handler receives this bit about the card on file intention, a number of things might happen:
  • The network or token service provider might return a different response based on this information.
  • The payment handler might use this bit to trigger a user experience for securing consent for storage of the credential.

[ianbjacobs]

During the 29 May discussion [1] we dug more deeply into use cases for which this parameter and possibly others might be useful. As a result of the discussion, brand representatives are going to do more research internally.

It is probably useful to broaden this issue to the question: "What parameters are useful (if any) to support token usage scenarios?" On the call today we heard some combination (possibly) of:

• Token requestor id. If known, this may be sufficient for the token service provider to determine what to return to the token requestor.
• If no token requestor id present, then tokenUsageType and (possibly) tokenRequestorType.

[ianbjacobs]

At the 12 June teleconference [1] we resolved:

• To include an optional cardOnFile boolean. The name was adjusted so that if a more comprehensive approach is taken in the future that relies on some combination of token requestor id, tokenUsageType, and tokenRequestorType, that there will not be confusion in the meaning.
• Default value is "false" which means "guest checkout" use case.
• The purpose of the boolean is to allow the SRC system to optimize the response based on token usage.
• The specification should indicate that this parameter may not be used by all SRC systems.
• The specification should indicate that SRC systems may perform the same or similar optimizations independent of this parameter.

[1] https://www.w3.org/2019/06/12-wpwg-minutes#item01