Kris: Landscape has been
fragmented; ISO 20022 seeks to address.
... we've been approached by the banking community to look at
the fragmented landscape to provide help
... PayLater is the resulting effort
... There was some discussion at Singapore on this and we've
had 2 meetings since then
Singapore discussion on Pay Later
[Kris lists who is involved in PayLater]
scribe: Berlin Group has come up
with an API for PSD2
... the PayLater flow is an extension of the Berlin Group
payment initiation flow
... We've identified 5 resources in the flow: consumer consent,
consumer consent status, loan offer, loan payment, loan payment
status
... these are part of ISO 20022 already
... we defined the data models from an ISO perspective and
resume them as such
... parties want to compete on content of loan offers, but not
on the component level so can use open standards
... SWIFT developed a Proof of Concept
scribe: we have a tool to help
find relevant components
... people can build APIs based on the same data model
... push to an API design tool such as Swagger
Kris: PayLater provides a way
offer loans at checkout
... consumer gets loan quotes, if the user accepts a loan, the
bank pays the merchant and the user enters into an agreement
with the bank
<Zakim> dezell, you wanted to ask about integration with CAPE and ATICA
dezell: How is the outreach to
CAPE and ATICA groups going?
... is there a use case map document?
kris: At this stage they are not
involved directly
... it's not that they are going their own way, but I think the
underlying data model is more or less the same
... the model is simple for now; working on a proof of concept
with a fast go-to-market deadline
... the goal is to have something out their by September
... Google looking at UI for this
<Zakim> manu, you wanted to ask about consumer consent, verifiable credentials, http signatures for auth.
Manu: Berlin Group has decided to
use the
Signing HTTP Messagessigning HTTP messages specification for strong consumer auth
... it's in their PSD2 proposal
Manu: have you explored using
verifiable credentials as part of the data model
... putting ISO 20022 in a verifiable credential? (See the Verfiable Claims Working
Group and VC Data Model specification)
Kris: I know we haven't yet looked at VC
<manu> Verifiable Credentials as used for Customs and Border Protection in US - origination of goods/products/organizations: https://lists.w3.org/Archives/Public/public-credentials/2018May/0015.html
[Ian: Due to lack of time I did not broach the topic of developing a PayLater payment method]
[Slide 2: CNP fraud is increasing]
[Slide 3: New technologies drive rapid change]
scribe: including regulatory,
non-traditional payment methods, AI
... can be challenging for retailers to figure out what's best
for their business and customers
[Slide 4: One-click checkout]
scribe: hard to implement a
seamless experience in light of liability
... retailers have to manage the balance daily
[Slide 5: Approval rates]
scribe: not where they should
be
... we are introducing friction in some ways that does not
support getting the approvals that we need
... additional data could improve approval rates and reduce
false declines
[Slide 6: Omni-channel]
scribe: customer expectations
evolving, including search in one channel but buy in another;
cross digital and physical channels
... even more challenging for retailers to transition across
channels
... technology can differ according to channel, can be hard to
track across these channels as a result
... e.g., purchase online and pick up in store can be difficult
if identifiers don't cross implementation boundaries
[Slide 7: Friction]
scribe: too many pay
buttons
... not getting better with proliferation of wallets
[Slide 8: merchant disintermediation]
scribe: redirects can create a bad UX and interrupting customer relationship is a concern of the merchant
[Slide 9: IOT]
scribe: increases some of the security concerns
[Slide 10: Transparency]
Laura: There is concern around
transparency around EMVCo SRC
... you can participate but it's a closed environment; can't
share with merchants
... W3C is going a good job on this front
... having transparency in the standards-making process is
important to the retail community.
... regarding "data use provisions"...if a wallet on the web is
used for payments, merchants want to know how the wallet
touches the data going through the wallet
... merchants want to know how the data is used.
... EMVCo SRC intends to mirror physical into the digital, and
some practices on data use might raise concerns
... merchants want to know who payment partners are.
... previously merchants knew who they were dealing with via
commercial relationships
... but some new flows involve parties that are not known to
the merchant
... it would be important for merchants to know who these
partners are
... transparency in spec development also helps
... before spec is completed
[Slide 11: Choice and competition]
scribe: consumer choice
... but also merchant choice (e.g., routing)
... we want to have choice in whom we partner with
... there is often times a cost-efficiency value
[Slide 12: Seamless customer experience]
scribe: retailers want to ensure
people can purchase products "the first time"
... to lower risk of drop off
[Slide 13: Consistency and alignment]
scribe: would be good to find
non-competitive processes
... retailers would like consistency and alignment in how
payments work (with transparency, choice, seamless
experience)
[Slide 14: safety and security]
scribe: we think there are some
standards that are not open, but W3C's standards do well
here
... support multi-factor auth (though not necessarily every
transaction)
[Slide 15: Balance investments/risk]
scribe: retailers might make
decisions about what they offer based on rules and liability
that might create a lesser user experience
... we are working with the networks to improve the UX
[Slide 16: Data ownership and control]
scribe: retailers feel strongly
that when a user purchases on a site, that is merchant's
data
... data should be used to get authorization and not for other
purposes
[Slide 17: Network best practices roadmap]
scribe: and to the end of the deck...]
Laura: Some of these things are
within W3C control; some are not
... so W3C could help on some of these priorities
<Zakim> manu, you wanted to ask for MAG perspective on Web Payments WG output -- Payment Request / Payment Handler / etc... is it making things better?
Manu: On slide 7 (Friction) how
is the experience with Payment request / Payment handler
going?
... have you heard anything from your merchants about adoption
plans?
... the hope is that we can address the friction point through
those APIs
... what have you heard?
Laura: Good question. Ian will be
doing a webinar on this to our Digital Commerce Committee this
summer.
... getting information to our merchants on what is going on at
W3C is an ongoing "Opportunity" I would say ;)
... so Ian is signed up to raise awareness
... we expect tech people to come to the webinar
<manu> Ian: I know Shopify have done some experiments w/ 30-35 of their largest merchants. I am hoping that Shopify will publish their initial findings this summer (but I don't have a time frame).
<manu> Ian: Last week we saw a few demos from Worldpay/Worldline/Lyra -- we're seeign a growing number of demos that bring together Payment Request / Payment Handler / Web Authentication / open banking APIs ... etc.
<manu> Ian: We could look at a PayLater payment method... starting to see pieces coming together... when you see streamlined strong auth experinece, it's very convincing.
<manu> Ian: We're starting to get feedback from people doing experimentation.
<manu> Ian: We're in the beginning of that climb to get merchants on board, good to hear about successes and failures as we move forward.
dongwoo: three of us are here
today: Peter O'Shaugnessy (devrel)
... Jinho Bang (co-editor of Payment Handler and implementer in
Chromium)
... here is a brief update on our status
... we released 7.2 of Internet Browser on Google Play a week
ago
... supports Payment Method Manifest as well as support for
native android payment handlers
... by supporting those two, Samsung Internet browser now
supports any native android 3rd party payment handler
... we've tested with a payment handler Tez (India)
... we also want to test with Alipay! (Max, hint hint ;)
... and we are also working on the payment handler API
... Payment Handler is behind a run-time flag but we are
working on it
... we are happy to enable the feature as we get more
demand
... we were supposed to have someone from Samsung Pay...
perhaps on another call
<Zakim> manu, you wanted to ask if Payment Handler support (for 3rd party payment apps) is planned in Edge or Safari, or if there is no support still on that front.
<PeterO_> Sorry I have to drop off to join another call. Thanks all.
manu: Exciting that Samsung
Internet Browser supporting third party payment apps, and in
Chromium as well
... Have you heard any news about Edge or Safari support?
... or other browsers?
Dongwoo: I have no updates
<manu> Ian: I can provide some information... this is a question that I raise on an ongoing basis with our colleagues. Let's start with Firefox.
<manu> Ian: Mozilla intends to work on Payment Handler, it's a resource question... finishing their Payment Request implementation... we're trying to get additional developer support to work on Payment Handler support this summer.
<manu> Ian: Meanwhile, Payment Handler will be released in Chrome 68.
<manu> Ian: We'll be getting more and more implementation experience that way...
<manu> Ian: Regarding Edge, I have not heard a committment from Microsoft yet... heard some more encouraging signals. No signals from Apple.
<manu> Ian: My focus has been Firefox and Microsoft and that will continue to be the case.
Manu: Update on the payment handler polyfill: It no longer works on Safari, we think that the change that cause this was unintential and should be fixed in a few months. We have seen some customer usage of the polyfill while awaiting payment handler API support in more browsers
30 July
dezell: Thanks to all presenters today
Ian: +1 to Samsung to continuing on a future call (going first, etc. :)
<todda> +1