<scribe> Scribe: ian
dezell: Welcome!
Amy: Thanks for inviting me to this call; good to be back
http://www.electran.org/industry-issues/technology/
scribe: 30+ years old...started
as offshoot of merchant acquiring business
... when we started, most of our focus was on more of an
old-school model of a sales channel
... terminals....
... but the model (and ETA) has changed
... we include 500+ member companies that cover the full
spectrum of delivering commerce solutions
... banking, security, loyalty
... joined W3C due to work around online payments
IJ: What are hot industry topics from ETA perspective?
Amy: Contactless payments is a
big priority in 2018
... to ensure some basic guidelines how industry can work
collectively to move forward in contactless
... third party players...payment facilitators
... risk management
... security
... Form factors...looking at auto, iot
<dezell> MnA = mergers and acquisitions
zkoch: We officially launched
move of Android pay brand to Google pay last week.
... we sought consistency of payment experience across
experiences...tap-and-pay, in-app, web
... it's a superset of brands...
... Google Pay supersedes google wallet and android pay
... we combine both tokenized and non-tokenized card
... from a user experience
... user's don't care about the details under the hood
... it works consistently across both first and third
party
... Google Pay leverages payment request API where we
can.
... on chrome, it relies on PR API
... if other browsers ship third party payment app support, it
will work there, too
... we are advocating payment handler api support
... Google pay may manifest itself as a standard button, or
within a payment sheet (from Payment Request API)
... that has to do with merchant expectations
... we are leveraging PMI spec, Payment Method Manifest
spec
... we still need to get payment handlers out the door
https://w3c.github.io/webpayments-methods-tokenization/index.html
IJ: What is google plan around tokenization work?
zkoch: No active plan, but it's
conceivable. But there are challenges.
... if a merchant wants to accept another *Pay, they still need
to sign an agreement
... our payload that Google Pay returns is out there and
public....
... I haven't yet done the analysis comparing to the
tokenization spec
IJ: Even if contracts are required, reducing technology friction is a good thing.
Zkoch: Right now there are only a
small number of parties so benefit is small
... we'd need merchants to demand it
IJ: It might be that others are incentivized to enter the ecosystem through payment handlers if they know tokens are already accepted
zkoch: I don't think we're there yet; merchants not yet accepting tokens significantly
dezell: I"m not sure cry for help
would come from merchants; might be from banks or networks
first
... amyZ brought up contactless payments a moment ago
... are multi-channel environments important to google pay?
what about use of payment request API in those contexts?
zkoch: We care about contactless (tap-to-pay).
IJ: Do you see web browsers having a role in contactless payments?
zkoch: My gut tells me "no" but I
haven't thought about it much.
... the immediate use case is not clear to me
<Zakim> AdrianHB, you wanted to ask about Play and processing of payments by Google
AdrianHB: I think I understood
the previous breakdown of the google payment landscape
... there was android pay with tokens, then Play doing
processing, and wallet was a value store
... is the goal here that they all sit under Google Pay and
play store uses the same thing?
... or mostly branding?
zkoch: Both
... behind the scenes things had been unified for a while; but
we didn't have the brand unification to go with it
... but not every card is a tokenized card yet
... users shouldn't have to think about it
<AdrianHB> AdrianHB: Is Google aiming to bridge instruments and networks that are currently not interoperable. E.g. Use linked bank account when doing a tap to pay with Google Pay
dezell: Many companies prefer to not require their users to download an app; prefer the web
<Zakim> Ian, you wanted to ask about strong auth
IJ: Do you have a flow with web authn?
zkoch: Yes, sheet + web site to
pay + web authn
... very compelling demo
... not all the pieces have landed yet but a lot of the core
pieces are becoming possible.
... the end user experience is very compelling.
[IJ describes flow that fits well with PSD2....wonders if Zach encountering]
[The flow involves strong auth, returning ECI in tokenization response, validated by issuer as part of authorization...for seamless payment including strong auth]
AdrianHB: Want to gauge interest
here in non-interactive payments
... some interest from the WOT WG
... and in inter ledger this is a use case we are focused
on
... it's not the kind of work that would fit comfortably in the
WPWG as-is
... the majority of our implementers in that group are browser
vendors
... for non-interactive, might involve a different set of
stakeholders?
IJ: Such as?
AdrianHB: The use cases we are
looking at, for example, involves payments between autonomous
systems
... e.g., around smart contracts...a system could pay for its
own bandwidth
... Might be some convergence with the automotive
stakeholders
dezell: Any thoughts on how current work might morph for these use cases?
AdrianHB: I presented a proposal
to IETF in Singapore
... the response from the people I presented to was lukewarm
since they were not payments people
... the challenge has been to find sufficient interest on
specific use cases from stakeholders
... people like the idea of things paying each other, but
there's no particular party for whom this is a big problem that
needs to be solved
dezell: Merchants will feel the pinch when there are 5 competing standards.
AdrianHB: I mentioned this on the
list because it's a topic of interest
... it's not that we are blocked on this; I wanted to let
people know this is interesting to us
(IJ: +1 to using this call to mention 'this interests me')
26 March, 10-11am ET
IJ: Any volunteers for other topics?
[None cited]