Web Payments Working Group

02 Apr 2020



Clinton Allen (American Express / EMVCo), Giulio Andreoli (Apple), Dirk Balfanz (Google), Andrey Bannikov (Facebook), David Benoit, Tomasz Blachowicz (Mastercard), Sofiane Boumedine (Canton), John Bradley (Yubico), Erhard Brand (Entersekt), Sumantro Das (1-800-FLOWERS.COM, Inc.), Chris Dee (FIS Global), Matt de Haast (Coil), Jean-Luc di Manno (FIME), John Fontana (Yubico), Dave Fortney (TCH), Max Geerling (Dutch Payments Association), Jean-Michel Girard (Worldline), Jonathan Grossar (Mastercard), Liquan (Max) Gu (Google), Puneet Gupta (Squarespace), Lauren Helt (American Express), Jeff Hodges (Google), Mathieu Hofman (Stripe), Adrian Hope-Bailie (Coil), Ian Jacobs (W3C), Joshua Karoly (Netflix), Kris Ketels (ISO 20022 / SWIFT), Mahesh Kulkarni (Samsung), Vincent Kuntz (ISO 20022 / SWIFT), Marek Kurylko (Mastercard), Tobie Langel, Florent Lambert (Lyra Network), Mercia le Roux (Entersekt), Denis Lesieur (Worldline), Bryan Luo (Amazon), Olivier Maas (Worldline), Wijnand Machielse (Berlin Group), Ajay Maddukuri (American Express), Chris Michael (Open Banking UK), Takashi Minamii (JCB), Fawad Nisar (Discover), Gerhard Oosthuizen (Entersekt), Jay Patel (American Express), Brian Piel (Mastercard), Anne Pouillard (Worldline), Jules Renier (Canton), Jean-Yves Rossi (Canton), Sophie Rainford (American Express), Hervé Robache (STET), Simon Rodway (Entersekt), Peter Saint-Andre (Mozilla), Ortwin Scheja (Berlin Group), Rouslan Solomakhin (Google), Nick Telford-Reed, Justin Toupin (Google), Arno van der Merwe (Entersekt), Luke Walker (Yubico), Danyao Wang (Google), Clément Warnier de Wailly (Canton)


  1. Welcome, survey, FYI about security analysis
  2. Merchant Feedback from Sumantro Das (1-800-FLOWERS.COM, Inc.)
  3. Open Banking
  4. Wrap-up, survey reminder
  5. Next meeting

Welcome, survey, FYI about security analysis


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

Merchant Feedback from Sumantro Das (1-800-FLOWERS.COM, Inc.)

Slides from Sumantro Das

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.


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.

Open Banking

See also STET Update from yesterday.

Open Banking UK

[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


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.

Berlin Group

[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

Wrap-up, survey reminder

<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

Next meeting

16 April teleconference


Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/04/06 21:36:43 $