W3C

Web Payments Working Group

29 Nov 2018

Agenda

Attendees

Present
Ian Jacobs (W3C), Herve Robache (STET), Luis Guzman (NACHA), Tony England (Bank of America), Chris Michael (Open Banking UK), David Benoit (Reach), Krystian Czesak (Shopify), Roy McElmurry (Facebook), Dean Ezra (Barclays), Ortwin Scheja (Berlin Group), Wijnand Machielse (Berlin Group), Vincent Kuntz (SWIFT/ISO 20022 RA), Jeff Wiliams (TCH), Rouslan Solomakhin (Google), Manish Haldankar (Open Banking UK), Adrian Hope-Bailie (Coil), Ken Mealey (American Express), Alex Dimitrakoudis (Open Banking UK), Matt Detert (MAG / BOA merchant services), Danny Russell (Worldpay), Laura Townsend (MAG)
Regrets
NickTR
Chair
Ian
Scribe
Ian

Contents


Agenda

<AdrianHB> ian: plan is to pick up discussion from TPAC

IJ: Goal is to find a common data model for credit transfers, that would work for a variety of open banking APIs

AdrianHB: Good summary, can we coordinate, can we come up with a payment method that works for everyone?

Chris: One consideration with merchant payments via the payment is you may have quite a few brands:

- merchant

- browser

- PISP

- bank

scribe: my concern (or opportunity) is how this appears to a personal or business customer
... while one can see how this would work technically, from an adoption perspective we need to look at the user experience of this
... interested in Shopify's view, for example.
... from a PISP perspective, they have a responsibility and some ownership of the user experience
... we have a few PISPs in the UK ecosystem (in testing mode)
... we have an opportunity to get them involved in the discussion around user experience
... so I think we should address the UX and branding elements before we go too far into technical discussion

Herve: Chris's comment resonates with me

vkuntz: Me too
... One common activity we need to see is to "get our act together" so we have a standardized API on the banking side
... the various open banking API efforts are defining a common set of API standards
... the second aspect is integration wrt Web Payments

http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/

https://w3c.github.io/payment-method-pisp-credit/

IJ: Web payments branding update - not actively moving that forward at this time; people seem to want to see familiar payment brands.

Chris: It may also be different in different markets
... maybe there is not a one size fits all solution

Ortwin: On the continent it may be different from UK
... in some economies cards are not preferred payment method, or where we have already push payments through screen payments
... for these brands it would be easy in the future
... paying by IBAN is not new
... direct debits are quite widespread
... for these to migrate from direct debit to push payment should not be too difficult
... wallet solutions will turn out to be very important
... I would not overestimate a branding issue

Chris: In the UK, card is predominant, along with PayPal as a wallet.
... every (EU) market will have a range of solutions
... I agree in general push payments is a much bigger thing in some markets

Herve: I would like to add that, nowadays, the EU payments market is still fragmented. PSD2 seeks to merge payer behavior through one preferred payment channel, which is the credit transfer in Europe
... what we are working on in Open Banking UK, STET, Berlin Group is an API based on initiation by the payer's bank
... this means that it's focused on credit transfer (esp. SEPA)

Herve slides from TPAC

vkuntz: I would like to comment on direct debit as well (e.g., with NACHA)
... so let's not lose site of direct debit

Herve: the API is based on the relationship between the PISP and the payer's bank
... a direct debit is initiated by the payee's bank, so currently out of scope in PSD2
... most direct debits in Europe are processed via payment infrastructure in place; no need for a PSD2 API

Laura: From a merchant perspective, we want to have choice
... in the US specifically, there are various products that we'd like to leverage more prominently within the Web, such as ACH or direct debit6
... there are leading financial institutions in the US that dominate the product suite; we encourage this group to pursue a variety of payment methods and offer choice to merchants, with a consistent user experience

<AdrianHB> +1 on implementers joining discussion (do we have any PISPs in the group, are there others we can try to bring into the fold)

IJ: What should we be focused on to enable the ecosystem? I am hearing payment method(s) for credit transfer, perhaps direct debit; pay attention to user experience.

<AdrianHB> ian: who do we need to get into the conversation to improve likelihood of adoption

<AdrianHB> ... is it browsers that need to implement something or is it banks?

IJ: Who needs to be part of the discussion?

Herve: For specification work I am happy to participate
... STET is not an implementer however.

IJ: Who are implementers you would see playing with us?
... who are working in sandboxes?

Herve: Yes, we can identify some (who work with a variety of APIs)

Chris: We have got a number of sandbox providers in the UK
... we expect a significant number of sandboxes in the UK
... march deadline
... Open Banking UK role does include implementation

<AdrianHB> It would also be useful to get an "overview" from the current participants that explains how the W3C APIs would be used to complete payments using open APIs

Chris: I think the PISPs will be the biggest drivers of this

[IJ thinks Herve's slide deck does that]

Chris: I would like to get a PISP (e.g., Worldpay) to help work out the UX issues

Ortwin: From Berlin Group, this is not so much a question of the API provider
... rather, for W3C much more interesting is integration with payment handlers.
... browser would not (due to regulation) speak directly to banks

Herve: My concern is workload most banks will face until march
... they have other priorities right now
... top priority is to get exemption and get ready for live launch in Sep 2019
... so may not be directly available for testing...but PISPs may be

<AdrianHB> ian: q is then, to what extent those on the call feel acting now is important or whether we should wait as stakeholders are preoccupied

IJ: How critical is the browser UX to the launch in September 2019?

DannyWP: We developed a demo

Worldpay Demo

scribe: the UX will be challenging, and also roles different parties will play
... how does user know their bank will be supported?
... you don't want 100s of payment methods (one per bank)
... users like logos (for trust)

<AdrianHB> ian: interesting arch questions

<AdrianHB> ... which stakeholder provides the payment handler to the user

<AdrianHB> ... and if they have a PH from (for example) their bank and it supports credit transfer, and the merchant calls PR and also supports credit transfer then the UX seems simple

DannyWP: You are correct that this is a good UX: user picks a bank payment handler by logo
... but merchant would need to register with all the different banks

IJ: What does that mean?

DannyWP: Merchant needs to register with all 9 banks in the UK and get an OAuth client ID

1) Merchant registration

Chris: The regulated entity needs to be connected to the banks
... it may be merchant or may be someone like Worldpay

IJ: Merchants are identifiable in the ecosystem?

(Not necessarily)

Herve: Merchants don't register; PISPs do

IJ: Two things go into a payment request:

* Data required from the merchant/PISP

* Conditions under which the response data is acceptable

<AdrianHB> IJ: In basic-card the response data is obvious (PAN, expiry etc)

<AdrianHB> ... conditions are things like supported networks

<AdrianHB> ... browsers job is to only prompt the user with handlers that can meet those conditions

<AdrianHB> ... similar pattern seems best for credit transfers too

<AdrianHB> ... q is what is the set of criteria that makes sense for credit transfer?

<AdrianHB> ... is the filter granularity banks, networks, PISPs etc

<AdrianHB> ... goal being easy UX

<AdrianHB> ... payment handler on the user side can also apply further logic to filter the flows it takes the user down

<DannyWP> unfortunately i have to jump off the call now

Dean: An alternative way to doing this...instead of making the API narrow to individual banks, maybe you can make it more generic

deanezra: Suppose you had a PISP that could handle multiple payment methods

<AdrianHB> The goal of the criteria is to ensure the user isn't lead down dead end UX flows. The analogy with card networks is most powerful (I think)

<AdrianHB> ian: the q is, how open should this be. Per bank payment methods seems too granular and complex

Herve: Since the payment handler API is a call before the PSD2 API processing,
... the only characteristics that are needed so far is (1) merchant ID (2) merchant account ID
... for the processor to be able to process the payment
... the payer's account can be acquired by the payment handler and forward to the PISP
... so from my perspective, for a payment handler to handle a credit transfer, all you need is 2 bits of data in addition to transaction data

Credit transfer payment

- Request data - merchant ID + account

- Filter/capability formalism: what are the conditions?

- Response data: status code, ... other bits

<AdrianHB> +1

Herve: I can ask some French PISPs for help

Chris: We have workshops every 2 weeks with a mix of banks and TPPs
... bandwidth is limited right now
... we could do a session on PR API to get a number of PISPs in the room

Ian: +1

Chris: Would be happy to have Berlin Group, SWIFT, etc. on such a session

<vkuntz> +1

Chris to Berlin Group: Would you be interested in joining one of these workshops?

Next steps

1) Chris and Ian to schedule an Open Bank UK workshop on this and invite STET, Berlin Group, SWIFT

2) Ian to schedule a next credit transfer call, perhaps after workshop call (but aware of march deadline)

Summary of Action Items


Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/11/29 16:43:13 $