See also: IRC log
Simon: Hello! I am at Mastercard and do EMVCo tokenization specs
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0005.html
https://github.com/w3c/webpayments-methods-tokenization/wiki
[We go to webex screen share]
Manash: after the call we'll update the wiki
[We review diagram]
Keyur: In some use cases, payment
app may do a step-up authentication (after user has selected
card to pay with)
... user may need to authenticate to the payment app
Manash: This may be a requirement based on geography, region, scheme
Keyur: Payment response is like
for gateway tokens, with some additional information.
... token info in the diagram is always "one time use"
... on subsequent checkouts, the payment handler will always
involve the payment app
... at least this would be the case for MC tokens for the time
being
Manash: But this could be extended to recurring transactions.
IJ: I suggest saying "Mediator"
instead of "paymentHandler" in the diagram
... We could put acquirer on the left and user between browser
and payment app
[We spend some time updating flow diagram]
Gateway params page: => https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params
Please change "CardBrand" to "supportedNetworks'
Keyur: Need amount and currency for various reasons.
https://w3c.github.io/payment-handler/#the-paymentrequestevent
IJ: remove total since that comes from PR API data set
Keyur: publicKey is optional in case of network tokens
oyiptong: I spoke to Stan (at
Stripe) who told me that, at least in the client, they don't
need the public key.
... however, some tokenization providers MIGHT need the public
key
... to give them flexibility in terms of their
infrastruture.
... I think "optional" is fine here
Manash: Do we need to plan for tokenization with 3DS 2.0?
[Repsonse]
Keyur: I think cardholder name
can be made optional
... Payment token or instrument token?
... ultimately the token is for payment, so I moved it to
"payment token"
oyiptong: To me the token represents the instrument, rather than representing "this payment" or "a payment"
IJ: What about just "token"?
oyiptong: that could work
IJ: what is diff between token and cryptogram?
Manash: token usually is the
DPAN
... you can have N DPANs for a given FPAN
IJ: Olivier, did you mean "cryptogram" in your proposal?
Oyiptong: Yes, but it may or may not be cryptographically determined.
<Ken> +Q
Ken: I'd like to advocate for
keeping the terms "cryptogram" and "token" separately.
... cryptogram in payments is a well-defined term
... and cuts across tokenized and non-tokenized
transactions
IJ: Let's define the terms in the wiki!
<Ken> +q
<Ken> +Q
IJ: Summary - the gateway and
network inputs are (nearly) identical
... the responses look quite different.
... Do we think this is a single payment method or two?
Ken: Thanks Manash and Keyur (and
Olivier)
... it could be useful to carve out when we are looking at
"what happens in the app" v. "what happens on traditional
rails"
IJ: Do merchants tend to accept
one type or the other type or both?
... if they are always accepting both, then let's define one
identifier.
Ian summary:
- could use some additional definitions and terminology harmonziation
- need to figure out 1 or 2 payment methods
<oyiptong> +1
<scribe> ACTION: Olivier and Keyur and Manash to do definitions and terminology harmonization and update the wiki [recorded in http://www.w3.org/2017/07/11-wpwg-minutes.html#action01]
<trackbot> 'Olivier' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., omaas, oyiptong).
Ken: Let's get worldpay and
shopify input.
... especially one 1 payment method or 2
proposed: 18 July