See also: IRC log
<scribe> Scribe: Ian
<shift4sms> is there a webex going? I receive a "meeting not started" message.
we have a Skype thing
hold on
<shift4sms> thanks
Please note: this week's call on gateway tokens not the full tokenization task force...but all welcome to join!
<ClintonA> I do not have Skype Connection details.
I am sending them to you
Manash: Let's use this call to
identify the major gateway token approaches
... where there are commonalities
... second, when a merchant integrates with W3C we want to show
that onboarding process is simple
... how do you create a process by which the merchant can
support multiple gateway tokens without having to specify each
item?
... from a large merchant perspective, what are the benefits of
gateway tokens? (and tokenization generally)
https://docs.google.com/spreadsheets/d/1v1BPvR7Z7apBrxSNgTF-ifYJAvLEECYh7tHW-cpSUq4/edit#gid=0
agent+ Simple onboarding possible?
oyiptong: I'd like to speak about
benefits to Airbnb....first is security
... it's more secure for our customers
... on our end, it allows us to not have most of our
infrastructure need to be PCI/DSS compliant
... but in terms of other merchants, it lowers the barrier to
entry to doing ecommerce
... activation cost is lower
... we still have pci/dss compliant infrastructure, but with
tokens, we can reduce the space of the infrastructure that
needs to comply
... also gateway tokenization lets us do offline transactions
security (recurring)
... having card on file in some form allows us to do different
types of payment methods
Manash: Right now, Airbnb had
form fill and Airbnb stores that card....and user can also use
paypall
... Let's say the card PAN number changes or card is reissued
or a fraudulent transaction is reported and a card is blocked,
how do you update your database?
oyiptong: We receive different
responses from the gateway telling us about the status of the
token
... if it's something that is retry-able we might try
later
... and we send comm to the user letting them know that a
payment was not accepted and they are returned to another
checkout page
... the way that we communicate with the gateway is
non-standard...gateways don't have standard (exception)
response codes and behaviors
Steve: I don't know if you can
standardize that part of it
... every payment gateway is different and a lot depends on the
marketplaces they focus on
... e.g., our API might be geared to hospitality industry
Manash: I think there are three use cases that are relevant
- one time transaction
- recurring transactions
scribe: other services that are
typically part of card on file is to manage card changes
... or card attribute changes
Manash: You want high acceptance
(and avoid false declines)
... for Airbnb, are there different gateways in different
countries?
oyiptong: yes
... having a standard allows for some gateway
inteorperability
... we also do this for risk mitigatino
... redundancy
... and competition
Manash: There are also
opportunities to optimize among gateways based on information
like time, acceptance rate, other parameters
... large merchants more likely to use multiple gateways (than
smaller merchants)
Steve: Regarding the tokenization
part of the question...there are really 2 types that are
focused on ecommerce....
... card on file (esp for large merchants)
... but for small merchants, there is often direct connection
to PSP (so merchant never sees PAN)
[IJ what is the terminology here? "hosted solution" v. ....?]
alyver: Stripe.js (creates token)
or Braintree hosted fields hosted in iframes
... or a hosted redirect
oyiptong: We have a page with iframes to gateways..but that still need to be PCI/DSS compliant. That's because we need to customize the page to make it work for the customer, and the various gateway providers don't provide that level of customization
Steve: Right, larger merchants want more control over the user experience
Manash: Open question - different
gateways handle card updates and fraud mitigation in different
manners
... I think our focus will be on commonalities
... if you are a merchant and you use PR API...the intention is
that you work with a few gateways,
... what is the burden on the merchant of declaring support for
tokens?
... will merchant need to indicate (in request data) supported
gateway tokens?
<Zakim> oyiptong, you wanted to comment on interoperability and to comment on interface
<shift4sms> sorry, just realized we were using queues
oyiptong: I think both Manash and
Steve have hit the crux of the issue
... we'd like a standard way to specify different payment
methods with different parameters
... yes, there needs to be an existing relationship with the
PSP ... we provide them with a merchant ID
... android, for example, has a config in the payment
request...as a payment method they allow for params to send
information to each gateway
... then there might be some communication (e.g., confirmation
that gateway has tokenized the PAN)
alyver: I shared that view on the
last call - the android pay PR API implementation allows you to
specify which provider, and the chrome implementation will call
the vault and get a token back and that gets passed back to the
merchant
... the customer doesn't know anything about gateway
tokens
... they just know they want to pay with their credit card
<Zakim> alyver, you wanted to discuss Shopify's implementation and usage of gateway and network tokens.
alyver: Our use cases are similar to Airbnb's...can go into more detail
<oyiptong> +1 on alyver
alyver: We are a platform that
supports 400K merchants, but they use our (hosted)
checkout...we are in the flow of the transaction...we have our
own PCI environment
... we securely store data...we also have "Shopify me" where
users can store information with us, to streamline checkout
across merchants running our platform
... in that way we have our own tokenization solution
... we have our own payment gateway but support several hundred
others downstream
... we support the *Pay flows
... we do offer support for third party gateways like Stripe
for some of our marketplaces and channel partners
... usually we've done the integration with the channel
partner
... marketplaces where merchants have relationship with
Stripe..they pass on token to us and we send it on through to
Stripe
Manash: How does shopify
tokenization work?
... user enters card information and creates "in house"
token
alyver: We recognize them for subsequent transactions (since we have card on file) and reuse the token
Manash: Would you also be sending information to Stripe?
alyver: No. When a merchant has a
relationship with, say, Stripe we pass information on to
Stripe. When customer is checking out (using Shopify API) the
gateway token is sent through the API
... we don't support all the gateway token providers; limited
integration
Manash: (Recap)....today
merchants say "they support gateway tokens"...and then they
could forward the information to the gateway with whom they
have a relationshiop
... currently you can't reuse a token across multiple
gateways...
<shift4sms> +q
oyiptong: Thank you for bringing
up the topic - reusing tokens across gateways
... there are advantages to that - makes granularity of
revocation easier
... right now we cannot specify which gateway to speak with ...
ideally the PR API could provide data about which gateway to
route to
... I imagine a world where we could specify multiple tokens at
once...that would be beautiful
Manash: How would that work?
oyiptong: I think it's a problem that larger merchants have. They want to increase acceptance rate and redundancy and competition ...having the ability to control on the merchant side would be the benefit
Manash: In order to support
multiple gateways....would help merchants achieve, say, better
rates / optimization
... helpful for me to hear the rationale
<Zakim> oyiptong, you wanted to comment on gateway specification
Steve: Are we talking about separating roles further here?
grr
(go on)
-----
* easier to get tokens
* easier to reuse tokens across gateways
<oyiptong> it's choppy
<Manash_MC_> Join by phone 1-636-722-2222 USA-Canada Local-Caller Paid (United States) English (United States) 1-816-713-4466 USA-Canada Local-Caller Paid (United States) English (United States) 1-844-802-4805 USA-Canada Toll Free (United States) English (United States) Find a local number Conference ID: 4957039
Manash: I think we have covered (1) why important to merchants
(2) token acceptance criteria
Manash: having interop of tokens
could provide advantages to large merchants
... regarding topic 3: similarities among token formats
alyver: I'd like to revisit
oyiptong's use case - redundancy across gateways and being able
to tokenize in multiple locations
... but most merchants are likely to have a relationship with a
single gateway provider
... in terms of use case, wouldn't you still require clear text
card for your own purposes before tokenizing with MULTIPLE
gateways?
oyiptong: Not right now. That is
correct we might have some use cases for PAN
... but I agree with you that the redundancy is a large
merchant need
... I think if we create a system with less friction we will
help merchants of all sizes
<alyver> I agree that it can benefit smaller merchants by reducing costs.
alyver: Agree that if this were
available to small merchants, could still help them e.g., in
switching providers
... at the same time, I wanted to bring to peoples' attention
here "PAN forwarding"...some companies have business models
where you vault with a company
and they will gladly forward a PAN to any of hundreds of gateways they connect with
oyiptong: I think the interop we are talking about here could facilitate that model
<Zakim> oyiptong, you wanted to comment on separation
======
* reuse tokens across gateways
* making it easier for merchants to get tokens when they build or use a checkout page
https://docs.google.com/spreadsheets/d/1v1BPvR7Z7apBrxSNgTF-ifYJAvLEECYh7tHW-cpSUq4/edit#gid=0
IJ: Are there other "interop things" we imagine doing?
shift4sms: What I think we would
need to define in this is almost like a DNS server capability
where the merchant says "I'm using such and such a
gateway"
... then a DNS lookup to figure out what the gateway
supports
... and client can get stuff
... then the token itself...maybe could be accomplished by
metadata
<oyiptong> Ian: your voice dropped
Response data I imagine:
* Token
* Metadata to use the token (e.g., type, provider, etc.)
<oyiptong> we can hear you
Do we know the request data and response data?
QuestionsL:
1) what does the payment method spec look like?
2) Other than a payment method spec, what interop goals do we have (e.g., token reusability across gateways)?
Manash: What we discussed today I
think answers those questions in part
... in terms of dataset, I don't think there's any
different
... suppose a merchant reaches a gateway and says "tokenize
this" I don't see much difference across formats
Flow:
Merchant: Get me a token!
Browser: Hey user, pick an app
User: I want to pay with this
App: Tokenize this!
Browesr: here you are merchant
Merchant: I don't want to see this, it goes straight to my gateway with "how to use" data
<Zakim> oyiptong, you wanted to comment on token flow
oyiptong: I think you got it
mostly right
... the merchants do want the tokens is so that we can keep on
file for recurring transactions
... we want to say which gateway we want to do the
tokenization
... ideally we'd like to get the token back
MANASH_MC: The other
situation...suppose W3C supports both network and gateway
tokens
... payment app can send back an EMV Token as well
... now the merchant is getting back an EMV token
... in that situation, the merchant should be able to handle
how it works with its gateway
IJ: We can treat EMV tokens the
same way
... merchants decide what to do with it (handle it or send
through API)
Clinton: I think at a high level, the type of token that is requested should be determined by the merchant request properties
(IJ: +1)
Clinton: If there's an API that's possible, it should be common across whatever the token type
IJ: +1 to (1) merchant decides
what they accept and (2) merchant decides what they do with
that
... let's assume we have the mechanisms available to enable
merchants to do that
https://github.com/w3c/webpayments-methods-tokenization/wiki
<oyiptong> +1 can help with parameters for tokens
https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params
<oyiptong> \o/
<MANASH_MC> +1 on Mission statement
<oyiptong> +1 on Mission statement too if you need help
<scribe> ACTION: Manash (e.g., to work with Ian) to update mission statement with refined understanding, scope, interoperability goals, benefits [recorded in http://www.w3.org/2017/05/30-wpwg-minutes.html#action01]
<trackbot> Created ACTION-58 - (e.g., to work with ian) to update mission statement with refined understanding, scope, interoperability goals, benefits [on Manash Bhattacharjee - due 2017-06-06].
<mweksler1> +1 on mission stmt
<scribe> ACTION: Oyiptong to begin to write down request/response params [recorded in http://www.w3.org/2017/05/30-wpwg-minutes.html#action02]
<trackbot> Created ACTION-59 - Begin to write down request/response params [on Olivier Yiptong - due 2017-06-06].
<oyiptong> Ian: +1 for mweksler and I on mission statement as well
IJ: We can review at 6 June call and have people say whether they agree with mission updates
6 June full task force meeitng
<MANASH_MC> sounds good !
<oyiptong> +1