See also: IRC log
=> https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0022.html AGenda
https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params
IJ: Keyur updates? Olivier diagram updates?
Manash: Regarding network tokens,
we have updated the first draft of the spec, but it's in
unformatted state
... this week we wanted to update the formatting.
... but this week is tough due to meetings
... so looks for this next week.
https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params
How to organize material?
1) How many payment methods?
2) How many specs?
IJ: Input same; response data different?
IJ: One spec or two? One payment method or two?
MattS: I plan to review the specs and the issues.
(IJ: Thanks!)
MattS: My off-the-cuff reaction
to Ian's question is concern about premature optimization
because the flows and use cases are different
... so my suggestion is to keep them separate as long as
possible and only combine once we see they are very
similar.
... so don't worry about 1 or 2 yet
... in the case of credit transfer, we have two payment methods
in a single spec.
... that is because they are so similar there is a lot of
reuse
... but the reason we have two payment methods is the flows are
very different (and responsible parties)
... so despite the data similarity, the flow difference drove
me to think of them as two payment methods
... and at first glance flows are different in
gateway/network
...summary: keep separate until later
<Zakim> oyiptong, you wanted to say, RE: scenarios, explain that the overall spec could be the same as network tokens, but the outputs different
<MattS> And I have no issue with that if that is the direction of travel
IJ: I would integrate for now (and then see how they look together)
oyiptong: +1 to going in current direction and see how different they look; so far looks workable as one spec.
MattS: the fact that it "could
be" one spec does not imply that it "should be"
... beware of spec size and challenge to consume it
... the primary audience for this spec is people writing
payment handlers
... but overall I agree with the idea "add it now and split out
if needed"
Ken: At last call we suggested
reaching out to worldpay and other acquirers.
... I think the PSP perspective is very important here
... better firsthand knowledge on the implementation side.
MattS: We have implementations
today and a number of implementations in a number of different
places
... each different scenario that uses tokenization might be
applied (differently) in different payment handlers.
... I anticipate that there will be two specs; but need to
review them
... we might incubate this as one spec, but when we package for
a larger audience, separation may make more sense.
https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens
(IJ: does not know if that is up-to-date)
mweksler: I agree premature
optimization is a risk and we should not assume that the two
modes of operation can be combined.
... I think one practical matter is that many of the parameters
are similar
... and many of the use cases or, rather, the ways in which the
payment request is going to be made are similar
... so to me the most important part is "how do we ensure that
the two methods use the same data / parameters"
... I would not want the specs to diverge unnecessarily
... or accidentally
<MattS> q
mweksler: so even if separate, let's make sure we use the same language and mechanisms in both, to enable future convergence
MattS: I'd like to better
understand the reuse you have in mind.
... one of the things I've been keen to suggest in the past is
the ability to reuse WebIDL and data definitions in order to do
things like superclass.
... I would agree with that.
... I also support the idea of sharing data definitions
... or even just english language usage
mweksler: +1 to both of those
This may be up to date as of last week's call => https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens
This may be up to date as of last week's call => https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens
oyiptong: I did play with
reordering of diagram last week...I think the network
interactions between the different entities are very
different
... user has a lot bigger role (it seems) in network
scenario
... I will create an issue and put the diagrams
side-by-side
MattS: Having a quick look online
at the diagrams, it may be that we are using different names
for the different parties in the flows
... we will need to standardize on the parties involved
Have a look at these:
http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/#flow
<oyiptong> +1
https://github.com/w3c/webpayments-methods-tokenization/issues/11
oyiptong: I'd like to talk about
specifying multiple tokenization providers
... if a merchant has multiple tokenization providers, they
should be able to identify them in an array
... why do merchants have multiple tokenization providers? (1)
redundancy (2) flexibility
clintonra: The idea is that there
is a need for merchants to identify for a transaction that they
work with N token providers
... and by requesting they will get back 1 response? All of
them?
IJ: I think this is a capability feature. Match on payment method, then capability matching on tokenization provider. User selection of payment instrument determines which token gets sent back.
<clintonra> +q
oyiptong: My thought was that merchant would get back N tokens.
clintonra: I hear what you are both saying but it doesn't align.
<Zakim> Ian, you wanted to say that doesn't wokr
IJ: I had not understood the intent to get back N tokens
MattS: I read the flow diagram as
the merchant backend choosing from among N tokens
... if that's correct, my observation is that it's overly
complex at this phase
... we don't have agreement on use cases yet
<oyiptong> +1
<clintonra> +q
IJ: Did you mean a single payment handler returns N tokens from N token providers? That would work
oyiptong: I did not mean that either...but that prospect is interesting...we are moving logic for routing into the client...but the way I was seeing it was that routing was done on the merchant side.
<Zakim> Ian, you wanted to ask a clarification
mattS: But the flow diagram the
payment handler talking with both token providers...so that is,
I think, what Ian was saying
... the merchant could then choose from among the tokens
returns (from a single payment handlers)
... merchant might choose for a variety of reasons, including
randomly alternating
... and I do see the value of it..but is perhaps early to
attack this use case.
clintonra: On step 5, the payment
instrument is selected
... steps 6-9 is the payment handler talking with tokenization
pvodiers
... support all the tokenization providers come back with a
positive
... I would have assumed in later steps that the token would be
generically associated with a token provider
oyiptong: I think token provider
without the number should be one of the token providers
... the diagram should show that at step 13 that it charges one
of the 2 providers
clintonra: If the tokenization
steps 6-9 are discrete functions that don't have to be done in
concert with the payment request, why couldn't each one be done
independently and subsequent to that you have the payment
request.
... why do they have to be combined?
... wouldn't the payment app do a tokenization with a provider
and later payment request happens?
MattS: One use case is 1-time use
with short timeout
... we need clarity on use cases
clintonra: If the tokens are limited in use (1-time, or limited duration)...i understand the payment handler could collect a few of them (outside of transaction flow)
https://github.com/w3c/webpayments-methods-tokenization/issues/11#issuecomment-314483114
<MattS> https://github.com/w3c/webpayments-methods-tokenization/issues/11#issuecomment-314483114
MattS: Some things to fix:
* 11 is "payment response"
<oyiptong> +1
MattS: One scenario is 2 tokens
for same underlying instrument
... also a single wallet might have multiple instruments in
it
... a payment handler might allow a user to pay with a merge of
payment instruments (e.g., one fails so other one is
used)
... I think the use case we are mostly discussing here is :
single instrument with multiple tokens.
oyiptong: Yes, that's what I had
in mind.
... one reason for that is to increase acceptance rate
<Zakim> oyiptong, you wanted to explain acceptance rate, redundancy and flexibility
mweksler: I agree that my
interpretation of oyiptong's proposal was single instrument,
multiple tokens
... and also agree with rationale of redundancy and
flexibility
... I think we should start with single instrument, single
token first then move to multiple tokens
<MattS> +1
clintonra: One thing I would
highlight looking at this initially is that you may have a
token provider that FAILS...hence value of multiple
... you may also want to affiliate with multiple payment
processors
... I would also argue that this problem might also be solved
by network tokens.
... if you have access to network tokens, then your one token
would work across multiple providers
IJ: Do 13-18 mean "the token-like thing" is not yet a token but can be given by the merchant to the token providers to get the "real" token?
oyiptong: Yes...that's to illustrate a use case.
<clintonra> +q
manash: I don't know from the
gateway token whether there is a list of params to be passed in
by merchants to get access to gateway tokens
... that could be a key or ID
<Zakim> oyiptong, you wanted to explain why we have numbered token providers
oyiptong: I want to respond a bit about why we have numbered tokenization providers and separate processors
<clintonra> +q
oyiptong: my initial assumption
was that they were one in the same
... so they are shown as separate though they could be the
same
clintonra: Part of the scope statement is that we are not talking about token sharing across parties....
<oyiptong> +1
clintonra: if you want to move forward with multiple token provider scenario you need to have 1:1 relationship with processor.
<MattS> +2!
https://github.com/w3c/webpayments-methods-tokenization/wiki
IJ: what are next steps with the issue, diagrams?
oyiptong: I wanted to have the discussion. As Michel said, I think this can be an evolution rather than first feature. Ok to start with one token provider first.
IJ: even with one token, you
still face question Clinton had.
... The question seems to be - how does it work when token
provider not same as processor?
oyiptong: I think issue is more
apparent when there are multiple
... but there is an unstated assumption that there is a
relationship
IJ: let's make that explicit
<MattS> I'm comfortable with this, I agree we are trying to solve too many problems at once and should focus on a small set of scenarios
<mweksler> Ian you dropped off
<clintonra> +drop ian
25 July