Web Payments Working Group

22 Oct 2018

Agenda · 23 October minutes


Rouslan Solomakhin (Google), Gildas Le Louarn (Lyra Networks), Nick Telford-Reed (Independent), Roy McElmurry (Facebook), Michel Weksler (Airbnb), Krystian Czesak (Shopify), Andy Estes (Apple), Matt Saxon (Worldpay), Frank Hoffmann (Klarna), Pranjal Jumde (Brave), Marek Kurylko (Mastercard), Cyril Vignet (BPCE), Vincent Kuntz (SWIFT/ISO 20022 RA), Ian Jacobs (W3C), Jean-Yves Rossi (Canton Consulting), Nicolas Ancot (Canton Consulting, Mohammed Dadas (Orange), Ken Mealey (American Express), Jeff Williams (TCH), Clément Wargnier de Wailly (Canton Consulting), Chris Marconi (Capital One), Cheryl Mish (Discover), Manoj Kannembath (Visa), Russell Kendall (Bank of America), Clement, Herve Robache (STET), Jonathan Grossar (Mastercard), Mark Cline (Visa), Eiji Kitamura (Google), Brian Piel (Mastercard), Jeff Jaffe (W3C), Karen Myers (W3C), Peter Saint-Andre (Mozilla, remote), David Benoit (Reach, remote), Lin Li (China Mobile), Matt Pisut (Microsoft), Bastien Latge (EMVCo), Marcos Caceres (Mozilla), David Ezell (Verifone), Manu Sporny (Digital Bazaar), Adrian Hope-Bailie (Coil), Giulio Andreoli (Apple), Dongwoo Im (Samsung), Chris Michael (Open Banking UK), Wanli Yang (Airbnb), Rami Josef (Worldpay), Bryan Luo (Amazon), Lawrence Cheng (Barclays), Carol Fletcher (Mastercard), Laurence Masson (PayCert)


Introductions and Ramping Up

<AdrianHB> [Ian requests that all read the Antitrust and competition guidance linked from the agenda]

[Nick walks through the meeting objectives.]

NickTR: Group health...we are a large group; can be hard to keep up
... AdrianHB and I would like to ensure that, as a group, participants are satisfied with direction and progress
... we welcome feedback on topics we need to be addressing or ways of managing the group.
Continuing goals - card payment security; adoption

<Ken_> +1

IJ: Minutes will be public

AdrianHB: GitHub is public and we welcome contributions from people

Ken: Question on the agenda - should we spend 5-10 minutes on liaison efforts?

Payment Request API Update

[Presented by Marcos Caceres]

Marcos: One note: I am wearing a dress today to raise money for charity; see the Do it in a Dress site.

Marcos: During Candidate Recommendation (CR) in the w3c process we get feedback from implementers and the larger community
... this phase of the W3C Process is an opportunity to improve spec quality and see if it works in practice
... as part of the standard process we write a lot of tests
... [we review automated tests, there are more manual tests as well]
... what we want to see to advance in the standards process is 2 columns of green; we are nearly there
... where there is not currently a lot of interop: first is merchant validation but soon this will be enabled in FF and Safari

Rouslan: We plan to implement all that. We are adding merchant validation to payment handlers, so merchant validation can be done in other payment methods

Marcos: Some of the failures suggest issues with the tests; they keep failing for all browsers and that is likely a test issue.
... in particular allow payment request attribute on iframes. Could use some help from Microsoft updating tests....am testing Edge 44; is that the latest version?
... Second, we start hitting interop issues is around canMakePayment()
... I think we may not have agreement on how canMakePayment is supposed to work

IJ: What is the plan for WebKit to change its canMakePayment() implementation?

aestes: We are changing it, but it may still not resolve issues
... we want to change it to be "you are on a capable device"

Marcos: We need to work out the story and perhaps change the spec text.
... also some issues with tests at the end of the test suite
... To automate these tests, web platform tests and web driver are used...but there's been some breakage on web platform tests lately; these come up as fails though they probably should come as successes

<Zakim> Rouslan, you wanted to talk about coming changes to canMakePayment() in Chrome

rouslan: In Chrome we are changing canMakePayment(). Currently we throttle on origin; we plan also to throttle based on payment handler
... previously you could check for "anything at all" but after our change you will be able to check whether you have "basic card or samsung pay or google pay....etc."
... but within a given payment method you can only do one of them every 30 minutes
... this change allows for merchants to show branded buttons
... e.g., One button per payment method
... you can call canMakePayment() per payment method to determine which branded buttons to show

adrianHb: The feature is there to allow the merchant to determine what to render
... the friction in the design is between privacy and the proper display of information (see issue 777).

IJ: Thanks to Marcos for all the work on test suites!

estes: I second the cheers to Marcos, thank you from the WebKit team!

IJ: What is the timeline for getting them done/implemented? What is the work required?

Marcos: Probably 3-6 months. I think we will have really good interop across three browsers very soon
... people doing nice job following though on commitments via GitHub

[We review the final CR issues]

IJ: So the blockers are:

* Issue 800: meaning of canMakePayment() (to be discussed today)

* Issue 59: Dropping card type (to be discussed today)

* Issue 600: Integration with Feature Policy (Editorial)

* Issue 753: Modifiers not used (Does not affect interop; spec needs to; Marcos has a fix that has not yet been deployed)

* Issue 684: Define handling of multiple applicable modifiers. (We know the desired outcome; awaiting resolution of dropping card type)

* Issue 27: Support for billing address in PR API (Marcos has a pull request; needs to finish writing relevant tests.)

IJ: Is there a need for editor meeting regularly?

Marcos: no

Dropping supportedTypes

[IJ frames the discussion of card types, used for filtering, and implication in user experience if card type filtering not available; see issue 59].

AdrianHB: If we drop supportedTypes, thanks to retry() the user experience may not be as significantly impacted as we previously thought. The issue is that browsers have a hard time determining card type; they are the wrong place to make this determination.

ancot: Is a BIN table sufficient? If not, why not?

Marcos: The people who sell BIN tables tell us the error rate is 10%, which is unacceptable to Mozilla
... they are also updated unreliably
... e.g., email us the BIN table monthly

MattS: Basic Card might be implemented by other parties than browser vendors, e.g., by processors
... people could create value-added payment handlers
... So I am hearing someone will have to create a "basic-card-plus" payment method.

Rouslan: In Chrome there are two types of cards - for cards stored in Chrome only, we don't know the card type
... we don't like the idea of prompting the user to indicate the card type

Marcos: We found in user testing that users can't distinguish credit from debit.

IJ: I am hearing MattS suggesting something like supportedTypes could be optional; and payment handlers can add value

MattS: I don't object to dropping it if we can add it later
... so if we drop now we have to consider how we will add it later.

Rouslan: I would support a different payment type for this feature; also could be URL-based

Frank: We don't need card type for our use case of our payment handler

Rouslan: Nor do we

MattP: We do our best to handle supportedType but the user experience is worsened

NickTR: I am hearing that where card type differentiation is happening, it's happening not on basic card, but in other payment methods
... such as Google Pay or Apple Pay...
... I'm landing on not having supportedTypes in Basic Card because you need more information than the PAN to get accurate prompts.

MattS: Have we seen the user experience with retry() when the merchant doesn't accept a particular card (type)?

Marcos: We could put together a demo but the proof is in user testing

NickTR: From a pragmatic perspective, demonstrating retry() could be done as a pre-amble to a formal CfC to remove the feature

Marcos: Three browser vendors are saying "broken from the start"

rjosef: Will removing it create a worse experience?

AdrianHB: The worse problem related to supportedTypes is that if the determination is incorrect, then there's a chance the merchant provides the wrong total; I think the user experience can be fixed outside the browser.

Russell: The old way of taking a PAN off of a piece of plastic may be true in this case ... but we are also looking more forward
... and hopefully provisioning in the future will be known by the issuing banks.

AdrianHB: I note that the supportedTypes feature is part of the tokenized card payment spec, it might be a better fit there.

NickTR: retry() gives us a better UX possibility

PROPOSED: Drop supportedTypes from Basic Card

<Rouslan> +1

<MattS> +1

<Krystosterone> +1

<AdrianHB> +1

<marcosc> +1

<MattPi> +1

<rjosef> +1

<Roy_> +1

<Chris_Michael> +1

<Ken_> +1

<gildas> +1

<frank> +1

<Marconi> +1

<wanli_yang> +1

<CyrilV> +1

<vkuntz> +1

ACTION: Ian to work with co-Chairs and Editor on a call for consensus to remove supportedTypes.

Meaning of canMakePayment()

[Discussion of "https://github.com/w3c/payment-request/issues/800">issue 800].

IJ: What are the various meanings of canMakePayment()?

estes: In ApplePay.js there are two flavors: (a) device capable to do Apple Pay and (b) device capable to do Apple Pay and whether you have an active card
... if you call Payment Request, we will do (b)
... we only return true() if the user has a configured card
... this is "wrong" because Apple Pay also wants to support enrollment on the fly
... so for the purposes of this discussion, we should change our implementation in Webkit to be (a)
... we don't do any rate-limiting right now though we are considering it

Marcos: In Firefox right now, we also want to onboard people, so if the merchant asks for canMakePayment() for basic card, we respond "true" all the time
... I imagine other payment handlers would also likely say "true()"

NickTR: in effect, then canMakePayment() means "is there a payment handler available for this payment handler"

Rouslan: In Chrome we have these behaviors:

MattP: In Edge, canMakePayment() only returns true if the user is logged in and has registered a card.

Dongwoo: In Samsung currently we do the same as Firefox - if basic card is supported we return true()

Roy: In Facebook, canMakePayment() returns true if there's a service worker installed

MattP: I heard two semantics:

  1. Can make payment as soon as user provides credentials.
  2. Can make payment immediately

IJ: What is Apple experience with the two functions.

estes: We mostly advise people to use the function that does the first of those two.

Giulio: We changed the user experience so the sheet comes up automatically
... you click the button; when you add the card then the sheet appears automatically
... that led us to encourage a basic check (with enrollment) instead of the more detailed check.
... also depending on where you put the button we may recommended the more detailed check

IJ: I am hearing Apple say that there are use cases for both meanings.

Krystian: I agree. Product detail page should have fast way of paying.
... on the card pay we are ok with onboarding process ....
... so Apple's implementation of two methods is very much in line with our use cases.

NickTR: I am hearing that there are two questions being asked....hasPaymentHandler() and hasCredentialInHandler()

Giulio: "Ready to use" for us means validated data

Estes: We also use merchant identity in distinguishing the two

IJ: I am hearing that the canMakePayment discussion will happen in a breakout

See canMakePayment() meaning breakout report.

Firefox Demo of Payment Request API

IJ: What is the status?

Marcos: This is Firefox Nightly (on by default in US, Canada, Germany for now)
... this is using demos from the site paymentrequest.show

[Demo is in Firefox nightly 64]

[Marcos shows zooming in the sheet]

Payment Handlers

[Ian's Slide presentation on Payment Handlers.]

[Rouslan starts with a demo]

Rouslan: First demo illustrates use of branded payment buttons, by Eiji Kitamura.
... information in sheet about payment handler comes from the payment method manifest
... we show the origin of the payment handler
... it's important to display the origin since that's how security works on the web
... we don't show "https" but these are always via https

IJ: What are the use cases for a Web-based Google Pay payment handler?

Rouslan: If you want to use Google Pay, say, on a desktop
... payment handler is better than a popup
... payment handler stays on top
... if it were an ordinary popup window, the user could switch away from it, which would cause the user to lose information about the payment in progress.
... the heart of the payment handler is just HTML
... you can set theme color in the top bar

[AdrianHB gives background on Web App manifest, which is the source of instructions on where to locate the logo used with the payment handler.]

Rouslan: Some lessons we've learned about payment handlers
... We assumed everyone would have a square icon, but some have rectangular ones!
... another lesson is that we expected that all dialog windows in chrome would be the same size, but in practice, some payment handlers would want some dialogs to be a different size
... so we are considering having an option for a bigger dialog window
... by default are service worker calls in chrome time out after 5 minutes

(Marcos: we have a timeout as well in FF but not on service worker)

Rouslan: We have learned that a 5-minute timeout is not sufficient
... we are going to change that to one hour and improve the messaging.
... A couple of features we've implemented:

<Roy_> worth noting, that's another distinct canMakePayment interpretation/use case

Lawrence: In this use case, the consumer is logged into a google account?

Rouslan: Yes; otherwise we would provide with a google login screen

Giulio: Does the "left arrow" at the top of the payment handler window work? What does it do?

Rouslan: Two behaviors:

Rouslan:We may replace left arrow with x for skip-the-sheet but can't figure out where yet

Jonathan: When you have the button on the merchant page, did you use canMakePayment()?

Eiji: We did not use it here

Rouslan: I think canMakePayment(), if the payment handler is installed, then the service worker does the logic

Ken: Thanks for the demo. Does this apply to a more mature use case where the merchant accepts multiple forms of payment, the user has multiple payment handlers....what order of payment handlers in the sheet?
... if the user wants to pay with Samsung pay, for example, and the user hasn't loaded it, what happens?

Rouslan: Order is determined by user settings
... those are guided by browser implementation
... we put, for example, apps above auto-fill cards
... we want to reduce exposure of PANs so we put payment handlers as a higher priority
... between the payment handlers, whatever is more frequently and most recently is sorted to the top
... if no payment handlers have be used yet, we use the installation time
... most recently installed show up at the top
... We use "Frecency" algorithm
... Regarding behavior, the various "*Pay" can be installed when user clicks buy button

Giulio: How do you confirm billing address?

Rouslan: We currently do not have a mechanism to give updates back to merchant to get updated total
... we know that payment request has shipping address, and if we give same functionality to payment handlers it feels like duplication
... so we have not figured out whether and how shipping addresses should be allowed in payment handlers and given to merchant to allow for total updates
... we do, however, allow for changes to BILLING address going back to merchant

Eiji: One challenge I noticed is ApplePay, GooglePay, PR API all have different shipping address structures
... it would be great to have standard address format?

Marcos: We have the bits in place for a general purpose address capability for the Web, but they have not yet been exposed.

Eiji: Both names of fields and which fields are present

[We then discussed payment handlers influencing payment request shipping address responses.]

[Frank Hoffman of Klarna showed a demo of a Web-based payment handler.]

Frank: We mainly do realtime financing.
... in this demo with a web-based payment handler we see two scenarios:

IJ: Did the user have to set up an account in advance?

Frank: No. In the first part of the demo, it's just-in-time installation
... in the second part of the demo we use the live JCrew site; they don't accept Klarna but you can still use the Klarna payment handler which supports basic card (using a virtual card).

IJ: Thank you. I am also interested in hearing more from people here about (1) browser buy-in to PH API and also (2) prototypes or other payment handler experiments.

AdrianHB: If there are any issues that are dissuasive to implementers, we should hear about them
... what would need to change in the spec to get more implementation?
... we would love to hear any issues

Roy: We also have a demo that relies heavily on payment handler API.

STET Update

[Herve Robache (STET) slides]

Herve_Robache: STET is a payment processor in France and Belgium. Also processes card auth network in France
... two years ago our shareholders mandated that we work on an open banking API for PSD2
... PSD2 transposition => moving into national law
... it's not happened yet in some places
... RTS (regulatory technical standards) on Strong Customer Authentication (SCA) are due 2019-09-04
... there are still a lot of issues to resolve around authentication
... STET has published multiple drafts, but is also not the only initiative around open banking APIs; see also Berlin Group, Open Banking UK, some national efforts, and some bank efforts

[We review PSD2 actors/roles.]

[Slide 11 shows links between w3c terminology / ecosystem and PSD2 ecosystem]

Herve_Robache: Note that same actor (e.g., bank) my fulfill different roles to have a stronger business offering
...PSD2 urges SCA (2-factor auth)
... there are some exemptions to SCA including small amounts and trusted beneficiaries
... Different parties can distribute payment handlers...in my slides I happen to show the PISP as the distributor of the payment handler
... in my slides I show 2 scenarios: (1) where PSD2 flows happen after the termination of Payment Request API and (2) where PSD2 happens from payment handler (thus, before the termination of Payment Request API).

IJ: This is the key slide - shows payment handler implementing the Payment Ha dler API and PSD2 requirements with SCA happening in the payment handler
... for both streamlined checkout and also PSD2 SCA

[We review initiatives to leverage ISO20022 for PSD2 APIs.]

Herve_Robache: Authentication is a big issue in PSD2
... there are national identity and authentication schemes (e.g., in Scandinavia, France)
... e.g., how to delegate to a third party
... there are three models envisioned (1) redirect (2) decoupled approach (national id or bank id), (3) embedded approach (the Third Party Provider (TPP) provides id and some auth factor to the bank)
... with embedded approach there are some concerns, especially around the use of static passwords

AdrianHB: On the flow diagram - once the responses come back; the payment report ...there's no opportunity for the merchant to cancel once the payment handler has been called

Herve_Robache: What is required by PSD2 is is that the payment has to happen via a regulated entity.
... The merchant can cancel the payment, but it depends on the payment processing
... for example, with an instant payment it might be too late
... for subscriptions, however, the merchant can ask the PISP to cancel the next payment

AdrianHB: So the response data is "the money is on the way"

MattS: I want to shout out to the credit transfer specification
... it aligns with the two flows that you described
... there's a third flow described (PISP credit transfer)

Open Banking UK Update

[Slides from Chris Michael (Open Banking UK)]

Chris_Michael: Open Banking UK had a different starting point but are moving to same place with Berlin Group and STET
... the standard that we have been developing is very similar (but behind in leveraging the ISO 20022 bits)
... our starting point in the UK was the Competition and Marketing Authority (CMA), a subset of PSD2
... the requirement was to establish standards for the 9 largest retail banks, which had to go live in January 2018
... last year our scope was extended by the UK gov to create a full PSD2 solution
... last month we published a complete PSD2 standard (third version)
... we expect the CMA to go live with that, 6 months before the PSD2 due date
... our scope was also extended beyond PSD2 requirements
... I think that this could replace card schemes for many scenarios
... four main APIs (account and transaction info, payment initiation, funds check, notifications)
... notifications for some payment scenarios where payment happens asynchronously
...Also aligning on security profiles: FAPI (redirect), CIBA (decoupled), Dynamic Client Management (onboarding)
... standards in this space are important since there are hundreds of third parties and thousands of banks
... regarding authentication, right now there is some friction in the user experience
... authentication is bound to each payment UNLESS the bank allows exemptions
... we don't think many banks will allow many exemptions, especially initially
... we've put a lot of focus on how auth should work and how the handoff to banks should work
... we have not adopted an embedded approach; there are issues with customers giving credentials to third parties
... but we think there are significant phishing risks
... our model is based on no shared credentials
... the slides show flows for different scenarios
... redirect, decoupled
... delegation to third party enables IOT type payments
... split out the user agent from the third party interaction offers some innovative payment or account access scenarios
... what we want to do is ensure that the standard enables these but in a way that is clearly defined
... we've got technical standards, UX guidance, and operational guidelines
... some commercial distinctions possible on top of standards compliance
... we are building conformance tools help banks and third parties
... we are also building a certification process
... so banks can show conformance to regulators
... we allow anyone to certify

PayLater Update

vkuntz: [Slides from Vincent Kuntz (ISO 20022 RA)]

<nicktr> vkuntz: presented this in Singapore so this is an update
...our working group has grown from 8 to 50+

vkuntz: In the flow shown, the merchant receives a single payment from the bank for the full amount
... we finalized the implementation; currently the group is reviewing it
... Should W3C work on a payment method specification?

NickTR: Does it need to be a payment method standardized at W3C, or can it be URL-based?

IJ: Who would implement this?
... and how much control of the payment handler ecosystem would be required?

vkuntz: We had 55 people at last meeting; 1/3 were banks ready to start implementing

Russell: What's the difference between accepting a loan v. a predetermined credit account they can authorize against?

vkuntz: Single loan for a single merchant

Russell: For high-value transactions?

vkuntz: Not necesssarily
... banks create accounts for their own customers (not for the merchants)

Russell: It's a credit account between the bank and the bank customer; PayLater authorizes the account via this API

vkuntz: Customers don't want to have to establish a new financial relationship for each merchant
... banks know the credit ratings of their own customers; not of merchants

AdrianHB: If this is just a credit push, does it need its own payment method?
... if the interface between merchant and user bank is the same as credit transfer, maybe we can reuse the same payment method

vkuntz: More info is needed from the merchant than for a credit transfer
... Will be implemented within the next couple of months

AdrianHB: Is this currently Europe-only?

vkuntz: I don't think so.

Russell: Is this based on ISO 20022?

vkuntz: Yes.

[See the European Payments breakout report.]

Card Payment Security

[Slides from Jonathan Grossar (Mastercard)]

Jonathan: Great to see such a large group here today; I am hoping we'll get feedback on card payment security.
... after the session it will be good to figure out the best approach to continuing the discussion
... I am new to the group and this is my first FTF meeting
... very excited to see the various achievements happening in W3C around payments and Web Authentication
... this opens the door to a great user experience, which can drive adoption of Web payments and reduce abandonment
... but we still need to do more to increase security
... we want to add security layers on the payment request API foundation
... to end remote commerce fraud
... the user experience should be the same or similar, but with different backend experiences.
... (Recap of fraud migration online)
... 96% POS approval rate, v. 83% approval rate online
... issuers see frauds and chargebacks
... what we want to achieve here is to reduce fraud and increase approval rates, to get closer and closer to what we see in the physical world
... and also reduce declines online
... success will depend on meeting stakeholder expectations:

What we need to meet objectives:

On tokenization:

Jonathan: Replace PAN with network tokens + merchant registration
... tokenization enables domain controls, lifecycle management
... merchant registration gives visibility to where token is going; ensure merchants are real

On consumer authentication:

Jonathan: 3DS2 benefits: (1) risk-based authentication, using 10x data than 3DS1. Risk analysis should suffice in nearly all cases without requiring an additional step-up
... but some regulations may require authentication (e.g., for transactions of more than 30 Euros) but in many cases, risk signals will enable risk analysis without step-up

<JeffW> ? Re:merchant registration

Jonathan: some merchants can use 3DS2 without step-up
... finally, FIDO authentication we'll discuss more at length tomorrow
... two main options for using FIDO (WebAuthn)....performed by issuer during step up
... or performed by merchant/wallet prior to 3DS2 flow, where authn results are provided as input to 3DS2 flows to remove need for issuer step-up

[Slide on 2 Factor authentication with FIDO and 3DS2]

scribe: in slide 8, second flow would have a browser or payment handler doing strong auth as input to 3DS2.

Jonathan: There are some assumptions; e.g., in option 2 of slide 8 there has been a previous enrollment with the issuer

IJ: Will banks delegate auth to third parties?

Jonathan: Appetite might vary but some likely to do so
... under some conditions.

ChrisMichael: I don't expect many banks to support exemptions ...they will require SCA in most cases, and that SCA cannot be delegated.
... they will accept some information from Merchant/PISP, but they will still require strong auth
... with PSD2 there is no contract between bank and third party

Jonathan: Agree there are additional 3DS2 requirements ... banks can reach agreements (e.g., with browser or third party payment handler)

Russell: How does PSD2 tie into the card payments?

NickTR: There is also a non-payment 3DS2 that can be used with non-card payments.

Jonathan: So the user experience of "fingerprint on your phone" (or similar 2-factor) is the goal user experience

[Regarding consumer trust]

Jonathan: We want to reassure consumers and provide them with full transparency about what will happen when they pay
... such as knowing what they can use at card selection phase, transaction confirmation, and compliance with GDPR

Bastien: 3DS is card-based authentication that can be used for non-payment transactions as well

[Next steps]

Jonathan: For discussion:

* Do you agree with the benefits?

* Can we organize a review of the SRC spec during the current public comment period?

* I suggest we merge the task forces (3ds and tokenization) into one as they are closely related

* We should seek to include user friendly FIDO auth as part of 3DS2

Jeff: You mentioned merchant registration....what's your perspective on that?

Jonathan: A lot of merchants have already registered through networks (or through PSPs)
... we might discuss additional ways of registering merchants (e.g, if browser becomes a token requestor)
... it's a question of getting scale

<mweksler> +1 to that

See also the risk analysis and the Web session during Tuesday discussion.

Facebook demo of tokenization

Roy: I had an intern over the summer who wrote a payment handler for Facebook that implements an earlier version of the Tokenized Card Payment draft.
... however, since we did the project the tokenization spec has changed for the better
... the demo shows functional capabilities but is not very pretty
... the demo shows two scenarios: the merchant has been onboarded, or has not been onboarded.

Roy: Onboarded merchants get more metadata.
... when the user pushes the buy button, you have the option of paying with the Facebook tokenization
... the Web-based payment handler shows Visa logo and masked last four digits of the card
... when he pushes the button, the merchant gets a payment response with the data of the (earlier version of the) tokenization spec

[Roy now shows demo without onboarded merchant; data set changes slightly.]

AdrianHB: So the user has a card stored with facebook

Russell: Who generated the token?

Roy: I don't know; there's a tokenization team working on this
... but we enable the merchant being able to get a raw string virtual card number.

Russell: We are are, as an issuer, helping to reduce some complexity
... for large merchants...directly flipping PANs into tokens in our token vault

AdrianHB: Those tokens can be passed to the network as cards?

Russell: Yes (TPANS)

Liaison Update

[Ian mentioned here a list of orgs he chats with periodically, including EMVCo, US Payments Forum, Global Platform, PCI, European Central Bank, NACHA (now in the Web Payments WG), Berlin Group, STET, and others.]

Breakouts and Reports

[After a show of hands we broke into three breakout sessions. We also contemplated a breakout on EMV(r) SRC v0.9 but concluded it was premature. We were directed to the EMV(r) SRC Press kit, which provides FAQ and webcast. Participants at this meeting were encouraged to provide feedback during the current public review period.]

Tokenization Report

<nicktr> ian: I'll report on tokenisation discussion

<nicktr> ...good discussion. We looked at fundamental questions including

<nicktr> ...dependencies on who is storing the token (browser? handler? merchant?)

<nicktr> ...another question: cross-merchant tokens from browser - how to handle different devices

<nicktr> ...a goal: kill basic card (or have browser implementers do clever things with basic card like send token data rather than FPAN)

<nicktr> jonathan: it would be good to get feedback from the browser implementers

<nicktr> ian: we discussed merchant registration mechanics

<nicktr> ...jonathan took an action to look for a definition of registration

<nicktr> ...registration makes binding and scope restriction easier (indeed, possible)

<nicktr> AdrianHB: when you talk about using basic-card more cleverly, do you mean like the Klarna implementation?

<nicktr> ian: yes

<nicktr> ...implemented in the browser without a handler

[See the continuation of discussion about tokenization on Tuesday]

canMakePayment() Meaning Report

<nicktr> AdrianHB: update on the canMakePayment() breakout.

<nicktr> ...proposal is to have two methods, as was discussed. For one, all implementations will align on the current edge and safari and firefox behavior: canMakePayment means "is a payment handler installed" but with an extension to allow dynamic enrolment

<nicktr> ...the second method (whose name still needs to be determined but something like "hasEnrolledInstrument") will mean that a handler is available _and_ a credential is available within it

<nicktr> ...the latter is primarily for the "instant buy" button use case

<nicktr> ...and anticipated in v1.1 of Payment Request API (that is, shortly after we have stabilized version 1.0 we will start to inclue support for the second method.)

AdrianHB: For canMakePayment(), this means that Chrome and SamsungPay need to make some changes.

Eiji: Apple's canMakePayment() is synchronous.

AdrianHB: General feeling was to not change any method signatures
... consensus is to not change any signatures and stick with asynchronous

<scribe> ACTION: AdrianHB to work with Marcos to update the canMakePayment definition in PR API, and work with Rouslan and Dongwoo to get implementation changes

<trackbot> Created ACTION-106 - Work with marcos to update the canmakepayment definition in pr api, and work with rouslan and dongwoo to get implementation changes [on Adrian Hope-Bailie - due 2018-10-29].

European Payments Report

NickTR: We had a good session on EU payments
... opportunities for convergence of different APIs
... I have taken an action that I will share with Ian to run a some sort of face-to-face meeting to look at those three APIs and the credit transfer spec to allow all three to leverage that basic spec.

<scribe> ACTION: Nick to work with Ian to arrange a chat between STET, Berlin Group, UK about credit transfer

<trackbot> Created ACTION-105 - Work with ian to arrange a chat between stet, berlin group, uk about credit transfer [on Nick Telford-Reed - due 2018-10-29].

NickTR: We'd also like a unique ID all the time per transaction.
... today PR API allows merchants to provide an ID (this might conflict with another merchant's ID)
... we also had good discussion about merchant adoption
... if we could get all the APIs working against credit transfer, that would be great to help with adoption

Summary of Action Items

[NEW] ACTION: Ian to work with co-Chairs and Editor on a call for consensus to remove supportedTypes.
[NEW] ACTION: AdrianHB to work with Marcos to update the canMakePayment definition in PR API, and work with Rouslan and Dongwoo to get implementation changes
[NEW] ACTION: Nick to work with Ian to arrange a chat between STET, Berlin Group, UK about credit transfer

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