<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?
[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
[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.
[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:
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.
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]
[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.
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
...summary:
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)
[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
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.]
[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.
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)
[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.]
[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.]
<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]
<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].
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