- From: Michel Weksler <michel.weksler@airbnb.com>
- Date: Thu, 03 May 2018 04:53:01 +0000
- To: Ian Jacobs <ij@w3.org>
- Cc: Peter Saint-Andre <stpeter@mozilla.com>, 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: <CACJH5UCWp7ONY5+SVJg7Z0EOWt7dA_JV2nZ4KsRdjDZX6yOuAA@mail.gmail.com>
Please see below... On Wed, May 2, 2018 at 10:12 AM Ian Jacobs <ij@w3.org> wrote: > > > > 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.) I think adding more examples to the "e.g." clause might make this clearer. We might say "e.g, for processing a single transaction or for guest checkout" But I also agree with Peter that guest checkout does not necessarily add too much value here as it implies a stance about whether an account is created at the merchant for the user. I think the spec should not have an opinion on this point (e.g. account creation). The spec should focus on indicating that this is for a single use. > > > > > 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… > The way I look at this is - "one time" tokens really mean a token that can be authorized once. Beyond that, there are many other things that can be done by a merchant with an auth, such as A charge An update to the authorization A partial refund on the charge Another partial refund on the same charge A new "add on" related transaction (e.g. the second partial shipment, if the merchant code allows it) etc etc So if we want to be totally descriptive in our name, we will end up with "one-time-use-that-also-allows-partial-capture-and-partial-refund-and-many-other-things", which of course would not be terribly useful. My point is - calling it a one time use token should mean that you can use it for a single authorization, and that you can then do anything else that a merchant can do with an auth (e.g. the list above). We can clarify all of that in the text, of course. > 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 <(718)%20260-9447> > > -- > Ian Jacobs <ij@w3.org> > https://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 <(718)%20260-9447> > > > > > > -- - Michel
Received on Thursday, 3 May 2018 04:53:41 UTC