Nick: Please complete our survey about this meeting. Also, note Master's Thesis on web payments security from Nils Wenzler (@crowgames);
PROPOSED: To thank @crowgames for his security analysis!
<Ian> +1
<nicktr> +1
<rouslan> +1
<ChrisD_> +1
<Jean-Yves_Rossi> +1
<bryanluo> +1
Sumo: Thanks for the opportunity
to speak with you today
... we're all passionate about this work. I have worked with
people across different verticals. It's been almost 3 years for
me now.
... I'd like to share some learnings from our use of PR
API
... please don't hesitate to ask questions!
... First, hope everyone is safe and secure.
... Some of my activities: launched progressive web apps in 2017
... Also part of Mobile Round Table Retailer Consortium
... early adopter of PR API in 2017
... some takeaways from our experience with PR API:
Sumo: We check product
availability at local level (via postal code)
... and availability on a given delivery date
... PR API is very good for this need
[Regarding the state of payments (slide 9)]
Sumo: credit card web payments
via client-side ui
... wallets typically implemented client-side with some
exceptions
... there are lots of wallets
... solve typically within OS, browser (PR API), or payment
method....but not all three.
Notes:
Sumo: Here's where we stand on some key topics:
Sumo: I think we need to mostly solve for (1) flexibility and (2) universality
[Stakeholders today: shoppers, merchants, payment processors, and payment gateways]
Sumo: But we might want to rethink stakeholders:
Sumo: How are we thinking about
role of regulators? Perhaps those discussions are happening but
not very visible
... Why we need to do more:
Sumo: Nice PR API feature is in
billing page and also product page.
... we removed card input form when we deployed PR API and saw
an uptick
... Some things to improve upon (see slide 20):
Sumo: Browser saved credit card.
My perception is that over time there has been loss of support
for browser-stored card ("built-in support for Basic Card").
... from the browser perspective
... It would be great to bring that back
... and I think we could advertise more and it would gain
traction
[Regarding address auto fill in the sheet]
Sumo: this is a highly erosive
step in PR API. If we could solve for this with type-forward
with a public-facing APIn (e.g., google maps), that changes the
game for people struggling to put in address info
... this would reduce friction
... another topic: no available analytics to understand when
users fall off...that would help a lot
... errors in addresses are highly costly. Would help if
corrections were moved upstream (rather than merchant
backend)
Sumo: Promo code would be great
in the sheet (especially for product pages)
... also would be good to have a separate field for gift-card
input field
... don't want to force users to compromise between convenience
and price.
... don't break out the API into components to do this, just
add to PR API
... EComm retailers are looking for identity solutions
... I think there's a compelling use case for injecting loyalty
into PR API
... points, etc.
... the use cases are plenty and we should explore
further
... simlarly with account credit. E.g., I'd like to use account
credit during a ride share.
... I think for gifting merchants like us, saving addresses by
merchant valuable
... during holiday season, merchants will see a higher
transaction of 2-party gifting
... having an address from the merchant account pulled into PR
API makes the API more relevant and freshens the data
... another topic: personalization ... movement toward
personalization of shopping experience.
... would be great to have flexibility in sheet for future use
cases
[On Security]
Sumo: Keep token encryption stateless. Add biometrics
[Summary of takeaways]
Sumo: I hope you find this info
useful. You have a strong community!
... feel free to email me (or GitHub, etc.
ian: You mentioned uptick on
conversion
... do you have any data on improved engagement or
conversion?
Sumo: We saw an uplift through PR
API.
... it was on all our android product pages
... we had a custom buy now button (with various colors and
fonts to give prominence)
... it's a continuous A/B test that we run
... PR API has, generally speaking, contributed to a significant
uplift
nicktr: Have you experimented with payment handlers alongside payment request?
Sumo: We have not gone that deep
into it
... a lot of our implementations were done on the front end ...
there were limitations in how we could use tokens ...we have a
some multiple auth and settlement use cases that are
complex
NickTR: The reason that I ask is
that some of the use cases you've mentioned could (I think) be
solved by looking at the payment handler architecture
... my other question: you spoke about "split tender" use
cases
... where shoppers are using a payment method and points or
other tender
... is that a common mode for you?
Sumo: Split tender is not a significant use case for us. This is a much larger use case for merchants who sell gift cards.
Danyao: Thanks for the
informative presentation. My questions are about promo code and
split tender.
... There are rich experiences merchants may want to build. And
that the sheet might absorb some functionality.
... my question is more philosophical: we have two approaches
for the API --- (1) full featured for lots of features (2)
building small primitives that merchants could compose
... for example, if we keep PR API as just a primitive to
retrieve payment credentials, but another API for shipping
addresses (accurately), and another for recognizing user
identity, etc.
... what are your thoughts on the tradeoffs...which approach
would give merchants more power to build the experiences they
want?
Sumo: I tend to think fewer APIs
better to speed up the user experience
... but we should have flags, for example, that tell the client
what to serve up and what to hide
... perhaps there is a gradient of APIs: "basic" to start, then
another one that integrates loyalty
... so 2 APis, but with the knowledge that the heavier one may
use more resources
<Zakim> ChrisD_, you wanted to ask about pre-filled consumer credentials and customer recognition - with proposal to retire the payment sheet?
ChrisD: My question was similar
to Danyao's. We've been speaking about various proposals over
the few days, but one theme is "retire the sheet"
... but that from a merchant POV, having the sheet with rich
features sounds like it adds value
Sumo: I think that the payment
sheet is a boon and should be used across the payment methods
out there
... Strong +1 to payment sheet
clintonallen: When I hear people
talk about UX, it seems like there are a sequence of steps.
Wondering if there are ways to do some of these things in
parallel or asynchronously
... some have to be decoupled from one another, and then in the
end (when total computed) they are re-synchronized
... I think that there are some opportunities here, and the
presentation highlighted that in a clear way
Ian: Clinton, that's an interesting observation. Would it be possible for you to write down the concrete use cases that have led you to that perspective?
Sumo: And I'd be happy to work with you on that
Danyao: You spoke about lack of convergence in wallets. What hurdles do merchants face as a result of that?
Sumo: Good question. Essentially
there is an operational benefit, reporting benefit, cost
benefit, marketing/partnership benefit. You want to streamline
many payment methods through one gateway if possible. That
makes developer code, analytics, UX all easier
... and if something needs to be troubleshot, there are fewer
dependencies to work through
... You have hundreds or thousands of engineers touching
code.
... at holidays we may have key partnerships
... and want to be able to easily flip a switch and turn on
payment methods within a container such as PR API
... want to ensure business continuity, strengthen
partnerships
Nick: Thanks so much Sumo!
... so important to hear from merchants
... we have been discussing a merchant group that we anticipate
launching in the coming months for even more input and use
cases
Sumo: I appreciate the
opportunity; glad the group is forward-thinking and
entertaining perspectives of other players
... I think there's good potential to make it work.
See also STET Update from yesterday.
[Chris Michael, Open Banking UK]
Chris: I will draw on notes but don't have a slide deck. Four main topics from me today:
Chris: We've been iterating over
standards for the past few years. Just published a new version
2 days ago.
... that version covers some PSD2 requirements based on new EBA
and other requirements on reporting, name of account holder for
PISP, field additions and extensions
... we've included some additional guidance on consent
management, security, etc.
... what's happening next is that there's a new CMA roadmap proposal
Still in consultation.
... key topic is VRP (variable recurring payments)...e.g.,
money top-ups, e-commerce use cases, bill payments
... involves long-lived tokens so auth is not required at each
payment
... alongside that, how does account access work when users
change accounts
... also confirmation of pay...how does this work in a PISP
journey. Our standards are based on
FAPI profile; that is evolving as well
[Regarding Directory]
Chris: The directory makes it
easier for TPPs to discover, connect, and validate certs
... we are seeing lots of differences in how trust changes are
managed
... makes it difficult for banks to validate certs.>
<nicktr> (It may be helpful to see the eIDAS primer)
Chris: lots of service providers
have taken different approaches and this is creating a lot of
problems in the ecosystem
... in the UK and Europe more generally
... we now have more 200 firms "live" in the UK or Ireland.
They are providing services or well on the way to doing so.
... another 200 ramping up
... they are in test or acting as TSPs.
... so there is a healthy amount of engagement
... API usage across CMA9 (9 largest UK banks as determined by the Competition and Markets Authority) has been growing strongly
monthly.
... well over 1M customers using open banking APIs (since Dec
2019)
... 305M API calls in February. most of those calls are to read
account info
... firms moving from screen scraping to APIs. Most screen
scraping in the UK has now stopped
... the two real big use cases we are seeing are: (1) business
accounting (2) personal and SME lending
... Payment initiation is now starting, but not yet available
across CMA9
... API availability is important; 96% availability is not good
enough for some use cases
... Most banks are supporting APP->APP authentication but
there is still friction that is too much for some use cases
such as in-store
... the bottom line is that there is some what to go in
auth
... we are seeing strong use cases for payroll,
business-to-business...that's where we expect initiation to
take off
... in response to COVID-19 there are some amazing use cases
(cf #powerofthenetwork) around lending and getting money to
people who need it the most, powered by open banking APIs. The FCA has issued a
call for input on open finance (pushed back to Oct 2020).
Extend APIs for use cases beyond PSD2
[Conformance]
Chris: OIDF and OBIE have
conformance tools
... requirement of CMA9 for certification; has been harder than
it should be
... we are running an online workshop on 27 April with the OIDF
... on conformance, certification, mostly around FAPI
... ping me if you are interested in registering for that
workshop
NickTR: Anybody experimenting
with combing Payment Request, Payment Handler, and Open Banking
APIs?
... we had done some experimentation on that front but not
active lately
... what could we do to foster cross-pollination?
Chris: I'm aware that worldpay
had done some demos. I think there is an awareness issue.
... good to get PISPs in the ecosystem to come together on this
for experimentation with PR API
<nicktr> (For references, see previous work on a Credit Transfer payment method spec)
Chris: I'm not aware of current experimentation today.
vkuntz: I did an experiment with a different open banking API. It could be translated to Open Banking API I suspect. It's feasible.
NickTR: It's interesting to hear that it has been challenging for banks to maintain availability of the APIs.
Chris: Some banks are closer to 100%. The issues have in part been with implementation of the API according to the standard, and some need to make changes but some banks can't make those changes in a live environment and so have to take them offline for short periods.
[Wijnand Machielse starts presentation of Berlin Group slides]
WM: NextGenPSD2...more than 3000
banks have imlpemented
... cover 28 countries
... for things like SCA and consent handling, etc.
... on the supply side, there is an advisory board with 61
TPPs, fin techs, IT providers, and so on are consulting on
future
... NextGenPSD2 is a standards org focused on tech and
organizational requirements
... we are not focused on implementation and scheme-related
activities such as testing and certification (which is
organized separately)
... we have been able to take multiple PSD2 transpositions and
interpretations into account
... the regulatory context is challenging; PSD2 is a directive, so it
is translated into national laws
... that introduces subtle per-country differences
... our APIs cover multiple SCA methodologies and multiple
banking functionalities
... a dedicated PSD2 API needed to mirror banking functionality
online, so we had to mirror a large number of available
environments.
... we also cover both retail and corporate enviornments.
... the API consists of (1) RESTful API (2) data structures serialized
in JSON or
XML
... TPPS are identified eIDAS certificates. But we also
integrate non-EU payments
... we have a separate and dedicated consent API
... we offer session support
... there optional services like API push services,
delta-reports, etc.
... the result is a compliant API that meets EBA requirements
and different national competent authorities
[Ortwin takes over]
Ortwin: We have moved into an innovation
phase
... we've started to work on services such as services that
make use of personal data
... e.g., notification of incoming payments
... discovery API
... if you have to connect to 300 api providers, you need
discovery
... working on new account types
... for payment initiation we are starting to work on payment
guarantee and request to pay
... we have first drafts of things like e-mandate for SEPA
direct debits
... we're quite advanced in definition of a pay later API
(consumer credit during initiation)
... work also happening on mobileP2P repository lookup
service
... use case example: Payment Guarantee (hotel in 2
steps)
... use case is to give authorization for payment 3 months in
advance
... when you check into the hotel 3 months later, the hotel has
a link to the previous transaction
... then reserves the money for the 2 days of your stay
... and during checkout they will book the money for this
transaction through the user's account
... this shows what the APIs might offer in the future
... we'll be discussing these use cases in 2020; and where
should we prioritize our standardization efforts.
... understanding the prevailing commercial priorities
[On Strong Customer Authentication]
Ortwin: We have left open to the
banks: decoupled, embedded, redirect approaches
... it's important to see that we have different regulations.
some banks may be required to implement redirect and nothing
else, or embedded and nothing else, or multiple
approaches
... there are also different priorities among TPPs
... e.g., smaller TPPs might prefer redirect
... the protocol supports preference negotiation if the bank
supports more than one approach
... the API also supports situations where the user has more than
one method available
... Webhooks for pushing information to TPPs is supported in
the standard
... lean push services for tech status changes is already
supported
... TPPs can submit PUSH URI through dedicated HTTP
headers
... we've started to standardize more heavy PUSH services
... but these will require subscriptions, so we've started work
on a subscription API
... I expect we'll resume standardization later this year after
some prioritization discussions
NickTR: What's the best way to engage with you?
Ortwin: Many Members of W3C are in our advisory group. Best starting point is likely email to the two of us.
[Kris Ketels presents Slides on ISO20022 and Open Banking harmonization]
Kris: We collaborate closely with
OBIE and Berlin Group
... want to focus on ISO20022 for APIs
... want to bring together the components of the ISO 20022
repository (for banking)
... and combining with APIs of preference, e.g.,
SwaggerHub
... we've built on the ISO repository a tool that is capable of
creating APIs based on the components
... once we have things like "account" registered with ISO
20022 Registration Authority, we can promote interoperable
APIs
... a second point I want to emphasize today is moving to
public APIs
... banks have moved from proprietary services (that is,
they were owned by the bank)
to exposing information to third parties
... this has led to fragmented landscape
... now there are lots of services owned by lots of different
players
... creates lots of interop nightmares
... SWIFT and a number of banks have launched the OpenBanking
Extensions WG
... like OBIE or Berlin Group, but we are focused on
commoditized open banking services
... some APIs we have:
Kris: have been working with
OBIE and Berlin Group on a common model
... it would be a pity that APIs covering the same surface not
be interoperable
... we'd like the data model to be shared (ISO 20022)
... we'd like to see convergence toward that common data
model
... we've also started work on variable recurring
payments
... and also started work on identity management
... 2 banks approached on identity management and suggested it
should be commoditized
... you don't compete on the identity service
... Santander has developed a mechanism to identify entities in
a trusted manner, and they are interested in broader
usage
... they recognize the value of building a common open
standard
... we want to define a global trust framework (with rules,
procedures, etc.) that participants adhere to
NickTR: Do you anticipate certification and conformance alongside the framework?
Kris: Yes, we would like to get there.
<Chris_Michael> Its FDX in the US
Kris: During TPAC 2019, Vincent Kuntz gave a presentation about leveraging PR API for SWIFT GPI
[Slide shows mashup of PR API, PH API, SWIFT GPI]
Kris: This slide shows the GPI payments tracker in the payment handler so that a merchant can track a payment in the same way that an ordering customer can track goods
NickTR: Great to hear from all of you. There's an enormous amount of activity around open banking. We are trying to get more experimentation. And build customer propositions. I agree that identity is a missing piece of glue
Danyao: Has anybody experimented with Payment Handler API? What can browsers do to better support experimentation?
Kris: I will look up name of person who I was aware of
IJ: What's the right venue for
fostering open banking experimentation?
... with payment request API?
Kris: I think the collaboration between W3C, OpenID, OBIE
JohnBradley: The open id foundation FAPI working group is certainly interested and has a liaison agreement somehow working its way through the w3c process to better explore some of these combined use cases. Once we get that liaison agreement out of the way^H^H^H^H^H^H^H^H completed, we can do work in the FAPI WG
<Chris_Michael> Great session - have to sign off - talk later
NickTR: Good discussion and
feedback on payment handlers on monday. Combining consent with
usability. We heard today from a
merchant. We need more voices from merchants; working on a
merchant business group to welcome more voices
... We heard more about WebAuthn ... I am convinced that that
work (including FIDO work of course) and if we can leverage
that in an identity framework (cf OpenID, SWIFT, etc)
... the conversations in this forum and among fora are really
important
... we also heard a bit this week on PR API v2 features
(loyalty, etc.)
... split tender
... vouchers
... We heard on Tuesday about SRC and I think there's an
appetite to get that working
... I'm grateful to everyone for attention an involvement
... many thanks to all the speakers (Nick named them all).
... to my co-chair Adrian, and to Ian for organizing and
scribing the meeting
... minutes will be available real soon and with Adrian, Ian, and I
will work on a blog summarizing the key points
... let's keep up the momentum; please experiment; please
evangelize; please come to meetings
16 April teleconference
[ADJOURNED]