Herve: Hi all. Here's the update
on PSD2 APIs in France
... since we met last the European Banking Authority published
an opinion that created some obstacles for provisioning PISPs
and AISPs.
... the French regulatory authority surveyed 14 French
banks
... the August results are "75% ok"
... each French bank has at least one compliance issue with the
new opinion
... either due to incomplete implementation of the STET API, or
"extra-API" features
... What we saw in August is that for AIS things are "pretty
good"
... with roughly 80 million requests from TPPs to French
banks
... what's more August is a holiday month, so this are pretty
good numbers
... ...banks have also begun to transition from screen-scraping
to the API
... PISP activity remains, however, pretty low
... the API issues raised during this review are small in
number, e.g., related to API data field meaning, or missing
fields
... we are working with banks to clarify these points
... version 1.5 of the API will be published next week
... there are 51 changes, 27 are small clarifications, 16 are
minor corrections (e.g., adding optional fields for info to the
TPP)
... there are 8 major changes such as new resources or API
entry points
... for post 1.5, we continue our coordination with other API
efforts like the Berlin Group, as well as EBA (including Open
Banking Europe), and SWIFT (on convergence of API data models
within ISO 20022)
IJ: Would SPC be interesting in open banking?
Herve: It could be useful, but
there needs to be a lot of work on other features (e.g.,
app-to-app)
... that is, frictionless redirect between TPP app and Bank
App
... that's the main focus for banks nowadays
IJ: What about web authentication adoption by banks in Europe? Any obstacles?
Herve: Web authentication is not
a focus currently. We are more focused on Oauth2
approaches
... and enhancements like FAPI
<Zakim> nicktr, you wanted to ask about PISP market
NickTR: You mentioned that there
had been 80 million requests around AISP, but less initiation
(PISPs)
... could you share thoughts on what is stopping the PISP model
from building momentum?
Herve: There are two factors. The
first has to do with French specificity regarding payment.
About 70% of transactions in France are card-based, so
transitioning to credit transfer or instant payment is a change
for users and will require some time
... the second factor [no pun intended] is that payment
initiation involves more complexity (cf ISO 20022
structures)
... we tried to simplify the structures in JSON but there is
still complexity within the structure. TPPs and banks need more
time to figure out how to handle these structures
efficiently
... I do think we are on the way up the ramp for PISPs,
however.
Ortwin: Thank you for the chance
to provide a Berlin Group update
... first, implementation varies a lot by country
... mostly depending on whether there is a legacy market
... where there has been a legacy market, adoption is around
50%. Adoption is at times more challenging
because of requirements related to fallback procedures in place
(screen scraping)
... as herve said, there's a big challenge now on app-to-app
redirection
... most NCAs (national competent authorities) have mandated
this be dealt with by year's end
... I think the major topic is to get people to used to the new
payment methods. It's more about user habit than UX
... The Berlin Group is rebranding to "Open Finance Task
Force".
... we are starting to develop a full open finance API
... we will probably publish a roadmap in November for the next
couple of years
... services for new account types, and full credit card
capabilities on APIs
... you'll be able to separate authorization, reservation of
funds, etc.
... these functionalities will begin to appear in the API
... and addition of "Request to Pay" functionality
... we are also discussing administration management APIs since
this will all be accompanied by contracts
... we intend to support automation through the APIs
(on-boarding, signing, pricing, etc.)
... it's a significant work package. we have two groups
(business and technical sides) starting to work on this
... It will be interesting to see how schemes arise around
this.
... we imagine banking communities creating frameworks of
contracts, e.g., for onboarding for such services
... I think this is in line with the EC's retail payment
strategy.
... they are expecting banks to develop these sorts of
programmes
... they also indicated their intent to "regulate this"
whatever that means
... in any case there is support from the regulatory side
... I expect most of the work will be done next year
NickTR: I don't really understand the nature of the relationship between the Berlin Group and the scheme formerly known as "PEPSI"...are Berlin Group involved?
Ortwin: No, not directly. Now
it's called "EPI"
... if you see the requirements from EC on SCT INST support for Pan-European payment solutions, a potential connection could make sense from an architecture point of view.
<Zakim> AdrianHB, you wanted to ask about clearing systems offering APIs
AdrianHB: Regarding the
integration cost and complexity. You mentioned "Frameworks" to
help. One way I've seen this addressed is, for example, in
India there is "integration in the center". PISPs can integrate
into the registry.
... do you see that happening in Europe to accelerate this
process?
Ortwin: I think this would happen
in the market. I see huge clearing houses starting to work on
this, as well as huge processors offering connectivity
services
... so I think it will happen but will be market driven.
AdrianHB: Would this exempt banks from regulation?
Ortwin: This is already supported by API providers. Processors are offering the services; if they are using certificates and it's outsourcing, then banks don't have to do this themselves
NickTR: Thanks to Herve and
Ortwin for the updates!
... makes sense to me that AISP activities would take off
first. Glad to hear PISP moving forward as well.
Ortwin: The EC's retail payment strategy could include a price regulation for SCT INST, which would probably support the usage of SCT INST via APIs e.g. in eCommerce.
[AdrianHB slides providing Web Monetization update]
AdrianHB: Recall that Web
Monetization is a declarative approach where sites can provide
a URL (via LINK element) where they can accept payments.
... the browser can stream payments to this payment
pointer
... we are experimenting with users being able to send tips and
donations to these payment pointers
... to accept payments, the merchant creates a wallet that
talks to the interedger network.
... they get a payment pointer corresponding to that
wallet
... ...each time the browser queries the URL, it gets back a
UNIQUE address on the inter ledger network (plus some
secrets)
... the site can listen to the "monetizatinprogress" event as
money streams to the payment pointer
... and the site can take actions in response to receipt of
funds, such as removing pay wall, showing confetti, etc.
... we've had a lot of experimentation in the past year by
content providers and platforms.
... e.g., Cinnamon is a video-hosting platform. When people
view videos on the platform, the streaming funds go to the
video creator, not the platform.
... we've also had experiments with games platforms, some
publications
... there's a contest we saw for small games (under 13K) where
the game can be enhanced if the user pays through web
monetization
... we worked with Igalia to have code added to chromium to
track deployment of web monetization
... although the deployment is small, it's been slowly
increasing
... in terms of browser support, there are Coil extensions.
Mobile is a big challenge due to lack of extension
support
... but there are interesting developments especially on the
"sending funds" side
... the Coil extension is open source
... meanwhile, the Interledger rails continue to expand
... we have focused more on Fintechs than banks
... for them (like Uphold, Gatehub, Stronghold), it amounts to
implementing an API
... the average size of a payment is less than 1 penny USD
Ian: What use cases are common for streaming payments?
AdrianHB: The streaming is
perhaps a red herring. We don't want to limit this to streaming
use cases. At the moment, the way Coil's extension works
(outside the standard), there is a monthly subscription fee.
The arrangement we have with our users is that Coil will
distribute funds to monetized sites.
... we think that low-value discrete payments will be a big use
case (tipping, donations)
... an easy way to think about use cases is how people make
digital goods purchases in apps...low-value frictionless
payments today in closed loop systems...we want to move those
to an open loop model
... We are also looking at other open payments ideas like P2P
beyond Web monetization
... so check out: openpayments.dev
... Web monetization is, essentially, the first deployed use
case for open payments on the inter ledger network, where
payment pointers are payment instruments.
... meanwhile, we've launched the Interledger Foundation in
2020 to build the Interledger network and develop the protocols
further
... we see an opportunity for (1) rails for low-value payments
and (2) open protocols for wallets and services that sit on
that.
... we also announced Grant for the Web, and we'll talk about
that next week during TPAC breakouts
... grant for the Web goal is to boost the use of alternative
monetization models on the web
... they announced some flagship grants this week for about
$7.5M.
... I understand the goal is to have the fund fully committed
within 5 years
Ian: How do PR API and PH API connect to this?
AdrianHB: Very tightly. See our
Rafiki demo.
... ...most of the experiments we did with the Rafiki money
wallet used Payment request with graceful fallbacks. We see
"Open Payments" as a payment method
... and if the user has a wallet that supports open payments,
they would have a wallet that can dereference payment
pointers
... we have a rough idea for using OAuth for authentication
(inspired by open banking initiatives)
... but all this revolves around URLs, REST, and content
types...so very Web architecture grounded
Danyao: A lot of the closed loop
options provide not just low value digital payments, but other
services like inventory management
... how easy is it for developers to add the auxiliary services
on top of low-value payments? And how important is it to
provide those extras?
AdrianHB: We don't have a lot of
experience yet.
... the only development we've seen rolled it relates to
receipts.
... but I agree with you. The biggest service you get from an
app store is discovery and distribution. But the Web offers
those services differently (e.g., search, links)
... payment is often integrated into services like
subscriptions that include more than just the payment part
AdrianHB: short answer: agree and we don't have a lot of experience yet
NickTR: Check out the Breakouts for TPAC 2020 next week
<AdrianHB> In particular the monetization breakout
IJ: Will there be blood on the floor?
AdrianHB: No. :) The question we
posed is "what is the role of standards?"
... how much revenue-generating pie other than advertising do
we expect, and how would standards support it?
Dave: I'll speak about TCH's RTP
network and a bill pay use case
... it should become apparent that some of the APIs discussed
in the WPWG could be relevant for the bill pay use case
... facilitating a direct deposit payment.
... Payments settle in
real-time through a dedicated account that TCH maintains with
the US Fed.
... settlement is final
... the network has a confirmation for every message. This is
different from other payment systems where it's assumed all is
well unless you hear otherwise.
... transactions are posted in real time to the receiving
account at the receiving institution
... the network uses credit transfer (push)
... we do have an interesting feature "request for payment"
that is live in the network
... so I could, for example, request a payment from Ian and Ian
could accept or reject the request
... that's the closest we come to a "debit"
... the payer always controls which funds are paid from their
account
... there's no concept in the network for a party to be able to
pull funds from an account
... the whole thing is built on ISO 20022 standards.
... this gives us building blocks for internationalization,
even if that doesn't exist yet
... the hope is that by having most of these systems on ISO
20022, connections in the future will be easier (even if there
will be legal / regulatory friction)
... regarding bill pay, over the last decade there's been a
shift in how consumers pay bills. First, more electronic (less
check)
... within the electronic category, there is more desire to
interact directly with the biller's Web site
... rather than interacting with the bank site
... top 7 bill categories: electricity, credit card payments,
cable/internet, phone, oil/gas, water/sewer, auto
insurance....and the rest is about 50% of volume
... We are interested in leveraging RFP and RTP features for
some bill pay use cases, and taking advantage of built-in
confirmation message.
... we imagine primary interaction on biller web site, but
authentication happening directly with the bank
... the mockups earlier this week (SPC) are relevant for this
pattern
[Dave shows some prototype of user experiences]
Dave: In first mockup, the user
receives a push notification on a mobile device. The message
indicates that there is a new bill; this is a request for
payment to the consumer's bank.
... the user goes to the bank app / site to manage requests for
payment
... the user might find multiple requests, and those requests
already confirmed and denied
... next slide shows details that could be displayed about the
biller, the bill itself. The bank app can show details, or
redirect the user to the biller for more details.
... then the user can confirm the payment...and due to
round-trip nature of the network, time will be required; a
slide shows the user that the payment was successful.
... We are also interested in not propagating user account
information; thus we are interested in tokenization of account
information
... some advantages like origin-binding, lifecycle
management
... part of consumer registration experience could involve open
banking (or "connected banking") experience where the consumer
goes through an OAuth step to authorize the sharing of payment
account credentials with a third party, and an option to share
that info in tokenized form
nicktr: We heard earlier in the week about QR use cases. QR and RFP seem like a natural pairing. Is that something you are investigating?
Dave: The short answer is
"yes."
... this is not a new idea. But it may make more sense once
billers have embraced the idea of real-item payments more
broadly.
... a QR code could help expand usage, but I think there needs
to be some adoption before this would make sense.
... larger billers, in my opinion, are probably going to prefer
registration at the biller's web site
... consumers already recognize that pattern
Ian: What is role of WebAuthn style authentication in these flows?
Dave: I see that happening at
registration time to receive requests for pay (even if one-time
experience is also an option)
... the highest friction occurs during what amounts to guest
checkout.
... which typically involves form fields and validation of some
data.
... user authenticates payments to the bank app (or delegated
partner)
IJ: Are banks interested in the customer visit, or in delegation?
Dave: Banks will want what the
consumers prefer. Today the experience is new to
consumers.
... some banks have not yet provided visibility to RFP
... I think as they do, consumers will go to banks
... then over time consumers will migrate to other parties
through delegation.
NickTR: If you had a magic wand and could get this WG to add capabilities you need for RTP/RFP, what would it be?
Dave: I think conceptually, checkout and bill pay will look very similar. That would be an interesting exercise to try out a real bill pay flow and identify what is in fact different. That would help us identify missing features.
Ian: Can we take offline whom to recruit (bank, biller) for experimentation?
Dave: Yes.
NickTR: We saw a bunch of
interesting topics this week. Want to take some time to start
to build shared vision of priorities over the next year.
... I have a strawman proposal
1) Get PR API 1.0 => Recommendation
2) Advance SPC
3) Continue to flesh out SRC support
4) Adoption
danyao: Regarding adoption, we
need to (1) make sure current payment flows still work in the
face of browser changes around privacy, for example. (2)
helping merchants to adopt new APIs (e.g,. SPC)...basically
doing things better
... I think that "making things don't break" is a higher
priority than "doing new things"
NickTR: Thank you for calling out that point
Danyao: Regarding Chrome, we are
very interested to work with developers to ensure that privacy
changes don't break things. I expect we will pick up our
previous privacy analysis work.
... e.g., 3p cookies to be deprecated by 2022.
... the chrome team is interested in fleshing out how these
changes will affect payment flows, and what new features are
needed before the 2022 deadline
AdrianHB: +1 to Danyao's
comments, but I think the WG can work in parallel. Some of the
new things are also envisioned to help some other things from
breaking.
... I'd like for us to think about what new things we can add
will support existing payment experiences and use cases.
... so a lot of the architecture thinking revolves around this
question: keep things working when capabilities change AND
improve the UX
... I would add to NickTR's list something related to
"Alternatives to payment handlers"
... also some interesting discussion happening around managing
privacy concerns related to hasEnrolledInstrument.
... I am interested in supporting two flows: (1) through
payment handlers .... supported by Chromium browsers (2) via
the merchant site.
... the latter case can allow for fallback flows where payment
handlers are not supported.
NickTR: Priority?
AdrianHB: Should be considered in parallel with SPC.
Gavin: +1 to Danyao and Adrian. We'd like to support SRC and 3DS in the face of changing browser behavior around cookies
Ian: Do the revised hypotheses I shared on Monday align with the list of priorities that emerged here? Adrian today mentioned "two paths" that we should be considering: payment apps and merchant-side. Different use cases may call for one path more than another. Or some parties may prefer one path over another. Or the "merchant-size" path might be a fallback when there is no payment app in the user's environment or their browser doesn't support payment apps. I like this model and it suggests that we will want to do more work to identify core capabilities (per the architecture discussion on Tuesday) and ensure they are available "on both sides." This may or may not lead us to change the APIs (e.g., by breaking out capabilities into smaller components). I agree with Danyao re prioity of implementation and pilot around SPC, but also with Adrian re doing things in parallel related to architecture. The reason for that is that we need to keep engaging with many stakeholders to ensure core capabilities align with reqs so that when we are ready for experimentation, the designs are already well-informed by real-world flows.
NickTR: Interested in hearing from browser vendors on these topics. Have heard a bit from Chrome.
Danyao: We are also interested in combining form-fill gestures and SPC authentication to reduce friction. No details yet.
NickTR: Any Apple perspectives to share at this time?
Andy: Nothing to share at this
time. I have appreciated the sessions this week and regret I've
been less involved in the payments work this year.
... I can share more thoughts by email later.
Mahesh: From a Samsung
perspective, we've been following the work closely
... we'd like to see how SPC works on desktop and then see how
it can work in a mobile context with Samsung Internet
Browser
NickTR: Any other opportunities for work that we've not yet covered?
Clinton: Over the past few months
leading up to TPAC 2020 I had thought we had lost some
momentum. This meeting has been extremely successful in
bringing us back to a sense of direction and urgency.
... Congrats on hitting the objectives we discussed in
September.
NickTR: Short pitch for the newly formed
Merchant Business
Group, newly formed (and for which I am the staff contact). We want merchant input on Web payments
but have consistently heard feedback that the WG meetings can
be too technical.
... the business group will NOT develop specifications (making
IPR commitments easier)
... we have two co-Chairs: John O'Brien (FIS) and Melanie
O'Brien (Coles in Australia). (No relation)
... Melanie's background is on accessibility, indicating broad
remit of the BG
... this is a call for your help in helping to get this group
off the group
... I may call on you to present to the BG to share your
initiatives, and to hear from merchants on problems they are
facing
... our hope is that we will have merchants of different sizes,
as well as merchant orgs like Conexxus, MAG, and
Vendorcom
... our first meeting will take place on 26 October.
Clinton: Regarding the Merchant BG, do we have to join the group to get involved?
NickTR: Note that W3C Members can
join (through their AC rep)
... people are welcome to attend the first meeting as
guests.
Canceled: 29 October call
Next full WPWG call: 12 November
NickTR: Thanks to all!!