W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2018

Re: [Tokenization] Attempt to synthesize Token Usage Type from 1 May discussion

From: Ian Jacobs <ij@w3.org>
Date: Wed, 2 May 2018 12:11:19 -0500
Cc: Web Payments Working Group <public-payments-wg@w3.org>, "Patel, Keyur" <keyur.patel@mastercard.com>, Richard Garreth Waller <Richard.G.Waller@aexp.com>, "Dix, Simon" <Simon.Dix@mastercard.com>
Message-Id: <FA1EA3CF-AA3B-4367-87AF-C0D5C0A19AF3@w3.org>
To: Peter Saint-Andre <stpeter@mozilla.com>


> On May 2, 2018, at 12:07 PM, Peter Saint-Andre <stpeter@mozilla.com> wrote:
> 
> Thanks, Ian! One comment inline.
> 
> On 5/2/18 10:03 AM, Ian Jacobs wrote:
>> Tokenization Task Force participants,
>> 
>> Yesterday we discussed [1] tokenization use cases and corresponding request data requirements
>> related to "token usage types”. I’ve updated the spec [2] based on the discussion and welcome
>> review. I’ve pasted the new text below as well. 
>> 
>> Ian
>> 
>> [1] https://www.w3.org/2018/05/01-wpwg-minutes
>> [2] https://w3c.github.io/webpayments-methods-tokenization/
>> 
>> ====
>> Token Usage Type values
>> 
>> * "one-time"
>>   The payee expects to use the token only once (e.g., for guest checkout).
> 
> Do we want to conflate one-time-use token and guest checkout? In my
> experience, guest checkout allows you to not create an account at a
> merchant website, whereas creating an account does not necessarily
> involve allowing the merchant to store a card on file for future use
> (but might be convenient to view past orders, create a wishlist, etc.).

(I look forward to hearing from others on this.)

> 
> Also, we noted in the conversation yesterday that a one-time-use token
> might involve multiple charges (e.g., because of split shipments). I'm
> not yet sure how that factors in…

I will update the definition to say that. (And hope that others with detailed knowledge refine/correct the definition.)

Thanks, Peter!

Ian


> 
> Peter
> 
>> * "card-on-file"
>>   The payee expects to re-use the token for as yet uknown future transactions, including payer-initiated transactions and payee-initiated transactions (e.g., for partial shipment, incremental charges, and resubmission use cases). Whether and how the payee requests a new Token Cryptogram for future transactions is outside the scope of this specification.
>> 
>> * "recurring"
>>  The payee expects to re-use the token exclusively for a recurring payment according to an agreement with the payer.
>> 
>> --
>> Ian Jacobs <ij@w3.org>
>> https://www.w3.org/People/Jacobs/
>> Tel: +1 718 260 9447

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447
Received on Wednesday, 2 May 2018 17:11:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 May 2018 17:11:27 UTC