NickTR: Welcome to the meeting!
It is your meeting; let Adrian and Ian and me know if you have
priorities we are not addressing.
... Meeting proceedings are public (not the case for all organizations).
[Nick show us some IRC command magic]
[Nick reviews the agenda]
NickTR: Here is my opening list of objectives for this meeting:
---
Remove any blockers to moving Payment Request forward in publication process
Explore enablers for wider engagement of community with Payment Handler
Hear about developments in new payment methods
Agree priorities for future work and re-chartering
Continue to develop our web payment community
---
NickTR: A big value of these
meetings is the conversations that happen outside the
room
... these relationships sustain us when we are not all in the
same room
... happy memories of reindeer and snowfall and the morning
light over the fen.
... if we can walk away Tuesday knowing how we will complete PR
API and Payment Method Identifiers, that will be very valuable
... payment handlers is another important topic - but not as
broadly implemented as we'd like
... so we need to understand more of what we need to be
doing.
... and then for payment methods I'm interested in hearing
about SRC, payments in Asia, Web monetization
[We start with updates from the Chrome Team]
Rouslan: The remaining Chrome
issue wrt advancing Payment Request API 1.0 to Proposed
Recommendation is actually related to Feature Policy
implementation, so we are working with them on it
... we estimate a fix in Chrome 80 (the current version of Chrome is 77)
... thanks to Jinho!
[We see a demo of the new retry functionality]
Rouslan: the demo shows the merchant calling retry with an error message customized by the merchant
[Ian Jacobs then presents slides on PR API 1.0 status]
<AdrianHB> ian: [talk through slides]
<AdrianHB> ... features: identified in 2018, stable since CR (April 2019)
<AdrianHB> ... [ talk through tests]
<AdrianHB> ... some small fixes required to get us to CR for frozen feature set
<AdrianHB> ... proposal to address objection from Sam Weiler (W3C Staff) is to replace boolean request for data with requests for specific details of user data (see the proposal)
<AdrianHB> ... Sam has indicated satisfaction with proposal but it has not been fully implemented in browsers
<AdrianHB> ... and WG has no implementation experience
<Rouslan> We suggest this feature go into 1.1 as we are already implementing 1.0 (i.e., spec version doesn't affect our work as a browser) but it shouldn't hold up having a solid spec (1.0) that has gone to Proposed Rec
<Andy Estes (by email on this topic> My position is that I don't see pull request 873 as blocking Payment Request API 1.0. I believe Apple's comfortable with the privacy characteristics of the existing address APIs, we've been shipping those APIs (or the proprietary variants of them) for years, and we have a merchant install base that is using these APIs in production right now. We must maintain web compatibility with these merchants, so removing the old APIs in a 1.0, or mandating the new ones, would mean that Safari could not properly implement the spec. I’d less severely object to merely adding these APIs to 1.0 as an optional feature because of the lengthy implementation delay it would introduce. Since the existing address redaction rules elide the most sensitive parts of an address, very often revealing no more information than could already be derived from an IP address, I’m comfortable shipping 1.0 as-is. That said, I believe pull request 873 represents a genuine improvement, and would support seeing it introduced in a later spec version, as I tried to articulate in my GitHub comment.
<AdrianHB> ian: people can deploy PR API today. We would like to hear from the group whether you are aware of merchants or other members of the community who are unlikely to adopt PR API unless the spec is a Recommendation.
<AdrianHB> nicktr: my sense is that getting to Recommendation is a confidence signal
<AdrianHB> ian: I think we have heard three proposals for proceeding...
<AdrianHB> (1) Request that PR API 1.0 advance to Rec with no mention of this feature
<AdrianHB> (2) Request that PR API 1.0 advance to Rec with this feature as optional for browsers to implement.
<AdrianHB> (3) Request that PR API 1.0 advance to Rec with this feature as normative for browsers to implement. This option will require extra time.
<mweksler> +1 on finishing 1.0 without the feature and marking it as optional
<AdrianHB> ian: there has been a request to apply this to billing address too
<rouslan> Option 1, please
<AdrianHB> +1 for option 1
<mweksler> +1 on options number 2
<wanli_> +1 for option 2
<estes> I agree marcosc
<estes> I think the WebKit impl of this would not change the Apple Pay payment handler
<AdrianHB> marcos: browser could apply redaction to data even if payment handler provides full address
<AdrianHB> ian: the data is in the payment method data
<AdrianHB> rouslan: it is payment method specific (billing address)
<estes> +1 for option 1
<krystosterone> +1 for option 1
<jv> How long is adding the feature going to delay the spec, months or years?
<AdrianHB> ian: we will still support both features for merchants. Chrome team suggest adding the feature will take 8 months
<Ciciley> Option 2
benoit: I would opt for the
option that does not delay the Rec stamp
... I would also like to see this feature for billing address
as well
... billing is only needed to facilitate payment
Marcos: Let's break out on this topic!
<tomasz> +1
<Roy_> +1 for option 2
show of hands for option 1: 9
show of hands for option 2: 14
show of hands for option 3 (in v1): 0
[Justin Toupin slides on Payment Handler]
Justin: We believe there are multiple benefits to the payment handler approach:
Justin: We continue to invest in the improvement of payment handlers:
[Demo: Payment handler can get updated total from merchant based, on, e.g., changes in billing address]
gerhard: I'm following in the specs. In the payment handler spec is this defined?
Rouslan: The event is part of payment request (paymentmethodchange interface)
AdrianHB: You can see that the
paymentMethodChangeEvent only tells you method name and "method
details" blob
... the question is whether we want the billing address to be a
standard model...that might let us simplify the topic of
removing pieces of billing address
[Slide on Just in time install]
Rouslan: We now make just-in-time
payment handler installation in more cases.
... so if the merchant accepts payment methods A and B and the user has a
payment handler for A, chrome will now show B for just-in-time
installation
[Slide on Payment handler event logging]
Rouslan: We have heard payment
handler developers say that developing the handler can be
confusing, so we have built a tool to help them
... some improvements include more verbose messaging
... we now put messages in the console while testing
... When deployed, those messages can be collected on the server side
and analyzed
... what we are seeing on the screen is the ability to see the
events fired in the payment handler and see what happens
[Slide on Delegation of requests for contact, shipping to payment handlers]
[Sahel shows a proof of concept; see also the Explainer from Sahel]
Sahel: we think that this will
reduce checkout times due to skipping the sheet
... we propose that at registration time, the handler tells the
browser what the handler can handle
... if the payment handler can handle a request, we don't show
the request in the sheet (and that is true for each type of
data: address, contact)
Justin: If the payment handler claims to be able to supply data, the expectation is that the payment handler will do so.
Sahel: Today we are doing partial delegation; another option is "all or nothing". That is: today we allow the payment handler to declare that it can support a subset of data, and we show the remaining members in the sheet for the browser to supply.
AdrianHB: You want to be sure the browser does not give data to the payment handler
Justin: That's correct
Sahel: Today the merchant has said what they want. They don't make any change to their call. It's just who handles it that changes.
Tomasz: These are the payment options. (Our demo does not show billing address)
IJ: Payment handler API does not yet show passing these booleans to the payment handler; that is on our payment handler API edit todo list
Sahel: What Chrome proposes is
new API features for changing the shipping address/options
... and notifying the merchant of changes so the merchant can
update the total
[More UX improvements in the payment handler implementation in Chrome]
Rouslan: We have heard that
people want a more native like user experience
... in our first implementation, the payment handler screen was 70% of
the window height
... that static height approach created some problems for payment
handlers requiring more space
... so we are experimenting with enabling payment handler UI to
expand to the top of the screen
Justin: The use case is payment sheets with long scroll bar...that would trigger automatic expansion in height
AdrianHB: Does this change the spec?
Justin: No. I'd like to hear from payment handler developers
(We count 7-ish payment handler developers in the room)
NickTR: Why are more people not developing payment handlers?? :)
Rouslan: Some payment handler
developers want the browser to handle some of the UI (e.g.,
list credit cards, authenticate the user)
... one thing that we are thinking about is "minimal UI
flow"
... in some circumstances, some payment handlers could say "I
would like to handle only name, total, account balance"
... in this demo, user just initially sees a prompt to
authenticate
... user can pull payment handler window up to see more
... we are thinking about various constraints.
... e.g., during registration there may be some sort of
negotiation of when to show the minimal UI
... one other thing is that if this UI is enabled, the payment
handler would not be able to show other UX
Justin: We have been exploring the range of complexity of payment handler UX
Gerhard: These are great. One of the ones that we'd been looking for is to flip into a bank app, interact with the bank app, and then flip back
Roiuslan: We have heard that use
case. I think we can use that today
... the bank app would alter their payment method manifest a
bit
... and if the merchant calls PR API with the information that
matches the banking app, then chrome will validate the app,
flip into it, and then flip back to the merchant
... this is how Google pay works today in India
... Anders Rundgren has built a demo of this
Ian: For the breakout: how payment handlers specify what they want.
Justin some questions for discussion in the breakouts:
- What do we need to do to make payment handlers successful?
- What needs to be part of the payment handler API?
- What parts of UX are exciting to people?
Ian: Another big topic for breakout session - how to get more payment handler support
[Tomasz Blachowitz slides on SRC]
Ian: We had hoped to have an introduction on SRC from a delegate from EMVco but we couldn't get that sorted out
<benoit> +1 for SRC summary
Ian: but we do have a document
that the Web Payment Security Interest Group been working on
... this draft is not currently public so it's still work in
progress
... (Pause while everyone reads the introduction to SRC on the
screen)
... Any questions on SRC?
[No questions]
Jonathan: I'll show progress
since the April discussion and demo.
... in April we illustrated how the EMVCo SRC specifications
could be implemented within PR API flows
... to show that the specs are not in competition but that they
can be used together.
... in the 5 months since then we have been looking into the
details of that integration
... what are the challenges we need to resolve?
... what data model is involved?
... how will identity and authentication work?
... how to identify the user to enable them to access enrolled
SRC cards
... how can we leverage Web Authentication?
... or identities from other identity providers
... the goal today is to walk through some user experience
flows
... have been working with Jalpesh (Visa) and Tomasz
(Mastercard) on the details. The flows are:
<tomasz> More details on SRC, including set of specifications, can be found on the EMVCo website.
Jonathan: As part of displaying enrolled cards for selection, there are use cases for both protected and frictionless access to the list of candidate cards. Once the cards are displayed, the user may may have to authenticate to pay with the card. In the case where the user had to authenticate to get the candidate list of cards, and to authenticate again to pay with the card, that would be two authentications. We want to avoid the user having to do too many authentications
Tony: When you say "Authenticate the transaction" what are you authenticating to?
Jonathan: Authenticating to the
issuing bank.
... that could be done in a few ways
... the goal is ultimately for the bank to recognize the
cardholder.
... this could be required by PSD2, or simply based on a risk
assessment
Tony: You take into account the
information provider in the PSD2 situation?
... are you authenticating both the "info provider (AISP)" and the "payment
provider (PISP)"?
... I may need some information before I do the payment.
Jonathan: We'll dive in after the demo
[Demo shows mobile checkout]
Jonathan: I am going to buy
shoes. I click the "Checkout" button which is the SRC
trigger.
... ah, but first some notes:
(1) payment method can be implemented by browser or third party payment handler
(2) This demo leverages Chrome's "skip the sheet" capability
Jonathan: some questions about
payment handler ecosystem to discuss
... so in this demo I am a new user (to the SRC
system(s))
... so I will enter a new card (in the SRC system)
Jonathan: I am glad Chrome is
working on expanding the payment handler window when there's a
lot of content!
... in this example, there's a user identity that is an email
address
... that data could come from a variety of sources, including
typing by the user but also some email known to the browser for
this user
... after I enter data in the payment handler I enroll it in
the SRC system. This demo is frictionless, but the demo could
do 3DS for example
Vishal: This is not exactly
frictionless. I have to wait for the customer to add a card to
SRC
... the flow seems similar to google pay
... why as a merchant would I opt for SRC when I need the user
to add a credit card.
... which might lead to a drop in auth rates
Jonathan: I mean by frictionless
that there was no customer authentication.
... in this demo, the user has never enrolled a card. It could
be that issuers already enroll a user's cards in SRC systems. That would
reduce user typing by having SRC enrollment managed by the issuing banks.
... part of the guest checkout experience in general requires
the user to enter some card; but we are hoping for more and
more experiences where the user doesn't have to enter
info...for completeness I wanted to also show the enrollment
path, but the transaction flows are smoother.
... This email is stored by the SRC system to identify a user
and cards. So when I change devices, I just have to enter email
on a new device.
... but for a new device, I will need to be verified, and those
approaches may vary
... e.g., OTP or trusting an identity provider, etc.
jalpesh: I agree with Jonathan's comments. The key point I want to emphasize is that this flow does not come into play unless the merchant says the user has to type in data.
justin_toupin: How do you see this working with other payment handlers? How would this work with an existing wallet?
Rouslan: Another way to ask the question: can you see PayPal, Google Pay, etc. accessing SRC for cards?
Jonathan: Yes
[Demo of returning user; first is with frictionless auth and second is with user interaction]
Jonathan: In this demo, the
payment handler queries SRC system(s) using the user identity.
If the SRC systems have enrolled cards, they are displayed in
the payment handler
... when I select a card, I get information about the card (and
the token payload)
... so in this demo the user chooses a card and the token
payload is returned through PR API to the merchant
... there was no need to authenticate the user to give access
to the cards enrolled in SRC
... and no need in this demo to authenticate the user for this
transaction
... as a side note: in a flow like this, 3DS could be invoked behind the scene
Vishal-Expedia: Can the merchant say what information they want.
Ian: In PR API, merchants ask for what they want, and the user experience changes accordingly.
Tomasz: SRC functions similarly
Lawrence: Payment doesn't happen yet when the user pushes "continue"
Jonathan: Correct; auth etc can
happen at that stage
... e.g., 3DS or other
... 3DS invocation could happen from within the payment handler
if the merchant asks for the payment handler to do it on the
merchant's behalf.
Lawrence: How do you see this experience compared to Apple Pay and Google Pay?
Jonathan: That's the next
demo
... we do some device auth as part of the payload you
submit
Sophie: Thanks, these demos are
really helpful !
... the question I have is - how does the handoff happen
between PR API and SRC system
... you could also do this without PR API
Jonathan: I am starting with the font end, then Tomasz will show backend work
Giulio: My understanding is that if the user had only one card enrolled (or 2 enrolled but 1 as a default) that you could skip a screen and go straight to the next screen.
Ian: Skip the sheet is a browser implementation optimization; once a payment handler has been launched, it's up to the payment handler to optimize its own experience for the user
Gerhard: In your flows
you already say "welcome back Allison"...you could show a
default card but allow the user to choose a different
card.
... that's just an example of a streamlined flow
optimization
(Consensus that payment handlers can optimize the UX)
Giulio: You could also have the option of adding a card in the same way
Joanthan: Agreed
... the real idea here is that when I click the "checkout"
button I see my cards (however optimized)
[Demo: Returning user on same device]
Jonathan: Suppose I don't trust
the device (e.g., a shared device)
... in previous example, for example, a cookie might have been
set after the user has been recognized.
... we can use web authentication to access the card list
... so I pick the payment handler, authenticate with my
thumbprint, then I see the list of cards.
... one question is the user experience on a device with
multiple web authn identifiers
... we did some demos and it worked with Chrome on Desktop but
not on Chrome
@@: When you showed the UI, was the content bound to the signature that FIDO gave?
Jonathan: The WebAuthn here is to
get access to card metadata.
... for that I need an identity that I can use with different
SRC systems
... there is an assumption that the user had already enrolled
previously (with FIDO keys)
... so that key is bound to the card list
[Discussion of how this works]
JeffHodges: This is not yet
specified but could occur as follows: the SRC system would say
"the user is not authenticated; you're asking me to return info
about a card but I don't yet know the user"
... there was no ambient authentication passed in.
... so if the SRC system wants to authenticate the user, it
would make a request to the device, and that's where
WebAuthentication would occur
... how WebAuthn is woven into SRC needs to be part of the SRC
spec (If I am correct)
Jalpesh: I didn't quite follow that. But I agree with Jonathan's perspective. We are saying the relying party is the payment handler. The payment handler in turn talks to the SRC system.
Tony: The registration would have to happen to the SRC system at some point. The SRC system would then have the public key of the client. It would be up to the SRC system to look up the key to find out what key ids are related and then those are displayed accordingly.
[We touch on the delegation of Web Authentication to TLD+1...a topic for tomorrow]
Rouslan: It's possible that SRC will invoke the authentication. But it's also possible that the payment handler does the WebAuthn and the backend trusts the payment handler.
Jonathan: SRC system may decide
to trust some
payment handlers who do Web Authn for access to
cards
... I agree there are two approaches: SRC does the
authentication (for access
to cards) or SRC trusts payment handler who does the authentication.
... again here we are discussing access to card list, not
cardholder authentication
jezza: I want to clarify
something around authentication. In the demo, the user
authenticated with the SRC system. If my user is in Europe and
the transaction is not exempted for SCA, then the user will
need to re-authenticate with the issuer.
... so now we are in the scenario where the user has to
authenticate twice
Jonathan: Before trying to answer
this question, let me show you another flow
... if we assume that I am a recognized user on a device and I
can access the cards, and we merge the two together. ...
... when I select a card, because of PSD2 regulation or a risk
decision, I may have to authenticate the consumer.
... it could be the merchant invoking 3DS or the merchant could
delegate to the payment handler
... the payment handler could invoke 3DS or
the payment handler
could authenticate with WebAuthn.....
... that means previously you had an enrollment for that card,
where the user then authenticates the user with normal
SCA
... it is possible for the first Web Authentication (to
access the card list) could be reused as input to a 3DS
process (once the user has chosen to pay with a given
card).
... the strong signal would then reduce the odds of
a subsequent step-up.
IJ: So the payment handler reuses the blob from the first Web Authentication as input to the subsequent 3DS flow initiated by the payment handler
Lawrence: What's in the payment method payload?
Jonathan: Can include token and
cryptogram.
... that is then used by the merchant or PSP for
authorization
Lawrence: If the payload contains the token which is uniquely identified to the consumer, would the issuing bank have to do the SCA?
Jonathan: That's separate from
the token. We are talking about authentication for the
transaction. There are multiple options including merchant
calling 3DS once they have the payload.
... or if it's the payment handler who has been doing this on
the merchant's behalf.
... The issuer is always responsible for the SCA, but
the issuer may delegate this function. The issuer may also
(based on
WebAuthn data) make a choice not to do SCA. That would
still be compliant with SCA either through delegation or
step-up if needed.
Nick: Agreed: the issuer is definitely responsible for the SCA. But that doesn't mean that they actually have to perform the task.
Tomasz: The SRC-I role is the
actor that invokes payment request on behalf of the merchant.
(The merchant could also be the SRC-I). The SRC-I receives the
credentials.
... the SRC-I can only receive displayable data (which merchant
can display to the user)
... the merchant's PSP could receive the part of the data that
is just for payments
[Tomasz shows data model from the DRAFT SRC Payment method]
<jeffh> thx
Tomasz: Note that we have some redundancy between booleans in PR API to request some data and the draft SRC payment method; we need to look into simplifying that
<AdrianHB> [tomasz talking through slides]
<Ian> Our goal is to define a datamodel for SRC and PR API that is common between networks
<Ian> ... next question will be whether or not we take this up as WG deliverable
<Ian> ... so next question is, can you make a tx using the data model?
<Tomasz> Not yet
tomasz: More work needed to complete the data model
Jonathan: If we want the data model to be totally complete, the question is who works on that, and how do we ensure it works with EMVCo.
Jonathan: So we probably need to invite EMVCo so send more people to the task force
nicktr: The proposal as it stands
assumes that the person building the PR API call is the
SRC-I
... or that they are downstream from the SRC-I....but I'm not
sure that's the correct assumption.
... that prevents the payment handler from being the
SRC-I.
... there are some things that look like payment handlers today
that are aware of the identity of the merchant
... the note I would give at this stage: I'm not sure we want
to assume the SRC-I is on the side of the payment
requestor.
Jalpesh: There is no reason a
company like Stripe couldn't be both the payment handler and
the SRC-I
... payment handler / DCF plays role on behalf of consumer;
SRC-I represents merchant (whether merchant or PSP)
... we don't have to call it the SRC-I in the w3c spec. Any
developer can call PR API. In EMVCo terms that's called the
SRC-I.
Tomasz: I think it's probably
important to discuss.
... if SRC-I does invoke PR API, the SRC-I can provide this
information.
marcosc: Please avoid "Object" in WebIDL due to security issues
Tomasz: Here's why we defined them as Object today - it's due to the EMVCo spec. We don't have specific typed objects in the SRC spec.
<Ian> In terms of user experience considerations, we want to ensure there is no gap in flow for users that have cards. A user with a card should have some payment handler available that either lets them select from among previously enrolled cards or add cards. We have talked about "browser default payment handlers" for payment methods (SRC or other).
<Ian> ... another UX topic: can we show individual cards in payment sheet?
<Ian> ... another topic we need to explore is user identity management (for logging into the SRC system)
<AdrianHB> ... where does it come from, who vouches for it
AdrianHB: We have something of an
entity modeling challenge.
... when we first designed this architecture, we had the
concept of a payment handler which is executable code
distributed by a publisher. And inside of that there are
instruments.
... but it doesn't map well to SRC...there is more required in
SRC on identity
... I think we can generalize some of the things that SRC is
showing us
Rouslan: Chrome Team would like
to see some SRC experience in the market that is working
end-to-end
... that will enable us to think more about how the browser can
optimize the user experience.
... Yes, we should continue SRC work.
Gerhard: We are wondering (as
reps of banks) how to add ourselves to the ecosystem. I have an
option of being a payment handler.
... the card issuer wants to do authenticate the cardholder
... is there a way in which the payment handler can hand off to
the issuer for the authentication.
... I think something's possible
... so the question is whether there can be delegation
... we need to be clear about what the issuers need to
do, otherwise the issuers are going to try to do too much, and
confusion will prevent adoption
NickTR: Have any schemes published SRC implementations or a timetable for such?
Jalpesh: Visa publicly announced
that we will migrate our acceptance and our experiences into
SRC. We haven't quite published a timetable.
... when available the systems will be available for testing by
various parties in the ecosystem (including folks here)
Jonathan: We made similar
announcements.
... launch is imminent
Tomasz: I agree we should continue; but also have more work on "how"
PROPOSED: The card payment task force should continue to work on an SRC payment method and its integration into the PR API ecosystem.
<AdrianHB> +1
<michelweksler> +1
<Sophie> +1
<rouslan> +1
<Fawad_> +1
<benoit> +1
<krystosterone> +1
<bryanluo> +1
<Dongwoo> +1
<jezza> +1
<Gerhard> +1
<jv> +1
<nicktr> +1
<dave2037> +1
<Ciciley> +1
<wanli_> +1
<heejin> +1
<jonathan> +1
<Roy> +0
<justin_toupin> +0
<frank> +0
<agektmr> +0
<AdrianHB> [Takashi Minamii slides on QR code payments in Japan]
<NickTR> Is the new QR standard in Japan aligned with EMV work on QR codes?
<Takashi> No
<AdrianHB> Can QR code be used for online payments?
<Masateru> No, it is focused on in-person
<Lawrence> [question about UX, missed detail]
<Masateru> UX is not as good as card but better than cash
<Lawrence> What is the motivation to switch?
<Masateru> The merchant is motivated and so offers cash-back to incentivise consumers
<AdrianHB> motivation from government is "anything but cash" so cash-back incentives are high
<David Benoit> Compared to AliPay, this seems like astatic data generated by the customer. What prevents me from stealing the code and using it somewhere?
<Masateru> Security is dealt with by providers, I'm not familiar with the details. It's not possible to reuse the barcode
<Gerhard> This looks like tokenization. Why not use the EMVCo standard?
<Masateru> I'm not familiar with the design discussions.
<Gerhard> I see the benefit of the form-preserving token but does it require merchants to add cameras to the terminal?
<Masateru> The majority of terminals already had the camera
<Gerhard> Which is more common, merchant presented vs consumer presented?
<Masateru> Providers all support both. The choice is driven by cost.
[Presentation by Sakiko Suzuki on payments in Asia]
Sakiko: Market affected by (1) various instant payment initiatives in Europe and (2) new payment methods from China
[Background on SWIFT]
Sakiko: SWIFT covers over 200
countries and multiple currencies.
... drivers of change: volumes, e-commerce, real-time,
regulation, open banking
... volume is doubling each year
... in Europe we provide instant payments across multiple
countries for cross-border payments
... in Australia we do so for all sorts of payments including
P2P and B2B
... SWIFT is focusing on cross-border payments; regulation is
really important
... there are issues like AML
... APIs help foster development
... we have three focus areas: modeling, publishing,
consumption
... GPI is a new system to provide instant payments
Sakiko: We are trying to connect
additional networks as well since we cannot provide all
solutions ourselves
... "NPP" (New Payment Platform) in Australia
... started in January 2018
... distributed architecture.
... allows Australian banks to do real-time clearing and
settlement
... distributed model ensures continuity of payment
services
... before NPP, Australian could not do real-time, 24/7
... based on ISO20022
... 1400 data fields available
... 24/7 real-time
... PayID or BSB and account number;
... we provide an API sandbox to facilitate development
... after 1 year, NPP has 75 Members connected to the network;
$75 Billion worth of transactions
... any type of payment can be supported by the network
... GPI has been around for 3 years
... next year, all SWIFT Members will be on this network.
... 98% of transactions settled in 1 day; 40% in less than 5
minutes
... most of the advanced banks can settle in 10-20
seconds
... GPI instant: 20 seconds end to end on average; maximum 60
seconds
[Trial participants include NAB, ANZ, ICBC, Bank of China, Bangkok Bank, DBS, UOB, Standard Chartered[
AdrianHB: If we push for real-time push payments, is the end goal retail?
Sakiko: I think it's possible. SWIFT can provide account-to-account transfer
[Demo of GPI with PR API]
Vkuntz: With PR API, merchant can ask the bank to track a payment and let the merchant know if it has not been received within 60 seconds.
[Demo shows a gpi-tracked payment method]
Vkuntz: the user selects an
account from which to make the payment
... selecting "confirm" causes payment information to be sent
to the bank.
... the merchant gets back a tracking ID
... then we can simulate the bank initiating the transfer
... then the payment method enables the merchant to know that
the payment has been initiated.
... so the payment handler has closed, and the merchant can
monitor the status of the payment.
... the payment response includes an identifier for the
transaction in the GPI system
IJ: What about authentication?
vkuntz: Authentication is in
g-link
... so we have it but have not applied it.
AdrianHB: What data is sent to the payment handler? How does the merchant identify itself?
vkuntz: There's merchant account
identifier.
... it's globally unique
Alex Liu presents slides from Airbnb
mweksler: Some points to think about as we go through the presentation:
Alex: Lots of slides but I will
go quickly
... Airbnb has a number of top-level businesses all of
which leverage an underlying
"Airbnb platform."
... one functionality within that platform is payments
... Airbnb has about 200 people working on payments
... we operate in lots of countries and accept a lot of
currencies.
... we go through multiple PSPs for redundancy
... we have our own coupons, credit plans
[Opportunities]
Alex: We wanted to redesign the
Web experience; lots of people start from Web (not
native)
... wanted a streamlined first time booking experience
... and thought we could use PR API to collect
information.
... we have a signup wall and thought we could use PR API to
streamline that process.
... we also wanted to use PR API to be able to support more
payment methods
... e.g., access to Apple Pay and Google Pay
... so PR API gave us access to more payment methods.
... in Brazil we have to collect a lot more information
...
... the longer HTML forms for data collection can lead to drop-off
... with PR API we don't have to manage all the form fields,
and resizing and display
... we also thought we could speed up checkout for use cases
where users already had *Pay setups
[Exploration]
Alex: We integrated it with desktop web via moweb.
[We see a demo using basic card, and a demo using google pay]
Alex: We saw a lot of benefits -
no complex forms, use existing wallets, access to more payment
methods, no custom billing form, buit-in infrastructure
... For us, we liked the standard API because it was easy to
swap in, and have it work across browsers
[Challenges]
Jonathan: Are you using PR API all the time, or just first time user?
mweksler: PR API remains an option, but previously used cards are available in subsequent checkouts (card on file)
Alex: If you start adding
card-on-file, once you have a mix of instruments (card-on-file,
card-in-browser, google pay) that can be confusing to the
user
... Biggest pain point around the use of PR API is the
lack of official payment
handlers.
... e.g., no PayPal
... even for the ones that are there (e.g., Google Pay), they are only
available through some (but not all) browsers
... You should be able to see all the payment methods on all
the browsers
... Second point is consistency across browsers. Suppose we use
Chrome basic card implementation...experience on mobile not
same as experience on desktop
IJ: Would label customizations in the sheet help?
Alex: Yes, that could help
... so we'd like to see (1) more official payment handlers (2)
support across browsers (2) configuration of form fields /
labels
... that is, customization
... even if the browser does not allow customization, make it
possible for us to know the strings that would have been
rendered and we can match them
... Second challenge was stored instruments
... if the user has some cards on file with Airbnb but also
cards in browser and so they get a difference experience
... not obvious to users how to find most up-to-date card
information
... so might be nice to integrate on-platform instruments into
the sheet.
... Another topic is "tokenization". If we were to implement PR
API, on the back end (e.g., Stripe, Braintree) the backend
integrations are different
IJ: Do you want a standardized API on the backend or a standardized payload?
mweksler: For a merchant would be great to have a standardized token shape, but PSPs may not want that level of interoperability
nicktr: I think this is a live
debate within payment providers whether to have tokens that can
be moved among payment platforms.
... there is nothing in the ecosystem today that prevents
transportable tokens from being built.
... you can use EMVCo tokens today
... but the tokenized card payment method could support
that
... I think that if there were 20 large merchants who wanted
EMVCo tokens, there might be product managers willing to make a
business case in their org.
benoit: Regarding universal
tokens - I would personally love that
... whenever anything changes in the payment chain, you need to
gain new authorization from the cardholder (this is a
compliance issue
... so seamless backend swapping is technically not allowed)
IJ: But at least you could get rid of some technical friction
mweksler: There are multiple ways that we could comply (including user agreement up front)
NickTR: The question is "who is the token requestor"...if the token requestor were the merchant (bound to the merchant) then do-able
mweksler: What we are after is slightly more nuanced - we don't want merchants to have to bear the burden associated with being token requestor. We want the PSPs to do the heavy lifting, and then we want to be able to use the tokens wherever we want.
Tony: Delegation is tricky (e.g.,
key exchange)
... so more tricky than just user consent
AdrianHB: That's probably why our efforts at a tokenized card payment method didn't progress.
rouslan: You expressed a
sentiment that if more payment handlers on more platforms that
would be great; I completely agree
... so the question is: what does Chrome need to do for people
to start using payment handler API
mweksler: Lack of payment handler
implementations I think is a big challenge; merchants need to
treat it as "yet another payment method" instead of the "single
payment method API"
... another topic is the user experience when there is both
card-on-file and card-in-browser
... some sort of merging of the two worlds would be
helpful
... I refer to this as "on boarding existing users to PR
API"
AdrianHB: The second topic is interesting
mweksler: Every large merchant
would have to write the same payment handler, which suggests it
is a possibility for standardization
... we don't store the cards (people do that for us)
... we'd like to merge them into PR API
(Tradeoffs)
- integration with airbnb systems
- customization
- ease
Regarding integration: it works really well today when replacing a single payment method.
Alex: e.g., PR API with just Apple Pay or just GooglePay
Regarding ux consistency:
- imagine large merchants adopting this - you'd have consistency across sites and that would build trust
- great for device-specific payment methods
but...
- not consistent with other Airbnb pages
Alex: different branding for
example
... also the ux is different across browsers (since different
platforms)
Regarding customization:
- would be great to be able to customized display sections, and get label consistency
Justin: What should we be investing in to get more payment handler adoption?
Roy_: One thing that would be helpful is to know the ecosystem of adoption of PR API
Justin: The volume in terms of transactions is growing
mweksler: I think you should encourage people internally that the more info can be shared the more adoption is likely to increase
Jeff Jaffe: I'd like to understand
more why the information about adoption is proprietary, or
whether we can have some conversations about stripping the
proprietary information
... even reducing to a single figure of merit (e.g., growing x%
per year)
jv: EMV manages to publish annual
maps about card adoption
... they anonymize data
AdrianHB: So each vendor could provide data to W3C and W3C could anonymize the consolidated data
<scribe> ACTION: Justin to check internally at Google about what can be shared
<trackbot> Created ACTION-128 - Check internally at google about what can be shared [on Justin Toupin - due 2019-09-23].
vishal: I think from a decision
perspective good to know (1) has there been an increase in
number of merchants adopting it?
... so doesn't need to be user numbers, can be merchant
numbers.
... regarding intro - we have examples in the payments industry
about branding Payment Request
<Ian> ian: We studied PR API branding and found there was little support because the observation was that PR API is not a payment method. Users recognize payment method brands and want to interact with those; there does not seem to be appetite for a new visual identity for the user experience that is built into the browser.
Vishal: I'd like to see a credit
card logo without specific brands, to indicate triggering PR
API
... PR API is a payment method from an end-user perspective
AdrianHB: I think the goal is
that users don't think of it as a payment method...ideally we
should figure out a way to make the experience fit into the
current branding requirements of some of the big payment
methods
... e.g., Apple requires an Apple Logo
... we have an unsolved problem about exposing the supported
payment methods of the user and exposing them as actionnable
buttons on the page
Rouslan: What is the biggest
obstacle to people writing a payment handler today?
... this will help us focus our energy
<benoit> Issue 870 about location rules is one for me, but likely not for many others
bryanluo: Two things come to mind
for us. The first question I will be asked is "What's the
business value for doing a payment handler?"
... it's not exactly clear at this point. The second topic is
more technical, but a couple of things come to mind:
... flexibility and extensibility within the API. As a payment
handler there will always be edge cases
... PSP integration is a big part of the payment handler
business model...where does it fit in?
... industry is moving away from iframe....does this PH
approach create another isolated thing
Rouslan: Thanks for this
information!
... Payment handler is a top-level window, so it does not
suffer from cookie restrictions on iframes
bryanluo: So it's like a popup that has a special UI?
Rouslan: Yes
AdrianHB: Regarding data model -the payment method owner owns the data model
Bryanluo: Ah, so there is already an open channel between merchant and payment handler
AdrianHB: Yes
... also note that OAuth experience in the PH modal happens
without losing the merchant context
Gerhard: If I get to the checkout
page and PR API is the third option, I am likely to pick the
first 2, so instrument-level display would be helpful
... It could also be useful for merchants to load payment
tokens in
<AdrianHB> ian: we do have a long standing request for "instrument level display" on the page
<Zakim> Ian, you wanted to ask Google for blog post on handler benefits
<scribe> ACTION: Ian to work with Justin and Google on writing up payment handler benefits
Justin: Our thesis is that PH API can improve conversion rates; that's a key data point; we'd like to partner with people to get that data.
Jeff Jaffe: The question at the
beginning was how to get more payment handler adoption. Lots of
good pieces "bottom-up"
... but a different approach is to ask which payment handlers
we most need.
<AdrianHB> ian: My observation is that chrome took that approach and picked the industry leader and continue to work with them. The one blocker is that the potential payment handler will only move forward with more browser support (specifically Safari)
mweksler: For Airbnb, definitely
PayPal would be great
... I think two that are not as big but also strategic are
Alipay and WeChat
Rouslan: Are you talking about China market or international market?
mweksler: Primary market would be
China. When you look at their online payment methods, the most
popular ones are the mobile ones that redirect to their
app
... it's not an easy payment handler, but it's interesting
AdrianHB: That integration already exists on some platforms (e.g., Android)
Rouslan: Side-loading apps would
not be good for security reasons
... Alipay did demos about integration with Chrome on
Android
... signature verification does not happen with legacy
redirect
mweksler: If you have a payment handler provided by Alipay you may not need to redirect
Vishal-Expedia: We have been
talking about 3DS 2.0. Entering the OTP is in the payments
page, which is great.
... seeing that flow compared to PR API overlay, its kind of
clunky to have an overlay compared to in-page display
... choosing of the payment method in the page would be
nice
... I don't see many merchants in this meeting; need more
exposure to merchants
IJ: Who besides MAG?
Vishsal: MRC
<AdrianHB> ian: we work with MAG (who are meeting this week so can't be here). Any suggestions for others are appreciated?
Vishsal: we have a meeting in January in Singapore
Jeff Jaffe: If I were running this as
a business, I would figure out how the WG should go after each
opportunity. PayPal conversations are underway.
... for Alipay, the head of standards of Alibaba is here this
week
... it would be good to build a story for Alipay
... WeChat is Tencent, also a W3C member
... as far as Merchant outreach, having a meetup between MAG
executive council and the WPWG might be a more effective way to
drive adoption
Rouslan: Question for browser vendors - should some implementation features of Chrome be "standardized" (even if not in spec):
- Just-in-time installation
- Skip the sheet
See details on JIT installation and skip-the-sheet
Rouslan: These are user
experiences and we've tried to not standardize them as a
result
... my feeling for skip-the-sheet is that should not be
normative in the spec, but could be mentioned as an informative
note
marcos: Agree that generally we would not put something like this in the spec
jv: But having same experience across browsers would help adoption
Marcos: Putting this into the spec may not help; browsers will do the right thing in order to provide the right UX
Rouslan: We have documented the conditions where Chrome skips the sheet
AdrianHB: Any changes we need to make to the spec to make it easier to implement as a browser?
Marcos: Architecturally we need
to do a bunch of things to support the spec.
... so don't want the spec to go too far ahead, but also like
the adoption experience so looking for a balance
mweksler: I wanted to add a
comment to the skip-the-sheet discussion
... I think there are other cases beyond "just one payment
handler"
... for example, configuration to allow me to use same payment
handler always on same site
... that info could be stored either by the browser or the
site
... e.g., Airbnb could store the preference and tell the
browser to skip the sheet and which payment handler to use
AdrianHB: I think that full delegation is an important piece of this - that the handler can handle shipping address
Sahel: In the demo we did today, if payment handler supports delegation, we do skip UI
Justin: We showed the minimal UI flow
<AdrianHB> ian: this is getting close to previous Mozilla comments on UI risks
<AdrianHB> marcos: there is a lot of UX work around permissions and constraints
nicktr: The "minimal UI" is a
special case of the special case
... if I were a Payment Method owner that was struggling to get
traction across a huge installed base,
... you could offer slick 1-click experiences because you'd
know, even with guest checkout, that the consumer has a primed
payment handler
... this seems like a great thing
... have you done work with minimal UI on desktop?
Justin: No not yet
michelweksler: I like the minimal
UI. I am wondering if we can go even further.
... is there a way for the user to say I authorize
micropayments up to a certain amount?
... could be less intrusive
Gerhard: I have these use cases:
1) The "no user auth" use case. We've already established credibility within a bank context. You flip into it and you flip out
2) FIDO. I the FIDO credential is in another domain, you could flip into it, do biometric, and flip back
3) Bank has an issuer wallet (there is a token + cryptogram in the native app)...needs to retrieve the cryptogram from the app
4) External device authentication (eg., browsing on desktop, authenticate via phone)
5) In south africa we've hooked up with mobile
operators to use USSD. Text-based interface;
phone wakes up; you type in a number to grant consent
... we do some sim-card protection
... it works on feature phones
AdrianHB: I want the minimal UI
to be more minimal
... for Web monetization, the use case is that I enroll up
front
... I have a concept of a balance..and an agent in my browser
making decisions about when to pay and how much
... our idea is that payment handlers are invoked, but the
payment handler is not interactive
<Ian> The payment sheet + basic-card is a variant of a minimal UI in some sense
<Ian> ... i.e. the sheet provides UI to the payment handler
<Rouslan> That's not how we have done it now
<Rouslan> ... we want to support push payments which will have a financial impact each time they are invoked
<Ian> It feels like you're doing the same thing so you could move the browser local basic-card payment handler into a "minimal UX payment handler"
<Tomasz> I like the idea of making the "basic-card" handler behave more like other handlers
Alex: I want to add onto that.
Maybe comes back to the question as well for the merchant who
has cards on file
... if we could shove instruments into the sheet, that's a
powerful use case for us.
AdrianHB: If we just enhanced basic card so that if you passed in a list of things on file, and if the user picks one, the response data is an index back to the card that the merchant provided
Alex: Passing in reference is interesting
AdrianHB: I think we want to move away from using basic card. I wonder if there's a way to move an instrument into a more secure version.
Tomasz: Airbnb could have its own headless payment handler that registers instruments with the browser.
<Mweksler> Can we unify the guest checkout + website sign-up?
UNKNOWN_SPEAKER: can we tie it
together with authentication?
... info about user, information about credentials, what's
needed to use them in the future
NickTR: There is a trusted site concept in PSD2 flows
mweksler: I am thinking more
about unifying the flow of identifying yourself with the
payment step and future login step
... maybe merchant says "I also want to create an account for
the user"
AdrianHB: I hear two use cases:
- Sign up and consent to my profile being used for payment later
- When making a payment agree to terms of service as well
agektmr: I think it's interesting
to add a password option so user can create account with new
password easily
... important to make clear to user the info is being used for
signup
AdrianHB: Right now PR API allows
merchant to request email. The merchant should be able to tell
the browser to tell the user that data will be used to create
an account as well
... that is, make it easier to create an account as part of
checkout
Tony: In a PSD2 situation, I may want to go to the information provider to get that information
AdrianHB: Question is whether we can enhance API to support authentication and later log-in
Rouslan: Can you tell me what you would do instead of a password? FIDO? Or OAuth into google or facebook? Or password generation?
mweksler: We have building blocks
to not do passwords. We could use OAuth or WebAuthn or
other
... what I'm seeing is an opportunity to tie things
together
Alex: You could delay password creation to later
Mweksler: There's an opportunity to get rid of passwords and use WebAuthn
Rouslan: So I'm imagining that in the sheet has an action button that says "Pay and Create Account"
mweksler: Need also to be able to
provide access to terms of service agreed to for sign-up
... in short: let's do all things at once rather than
serially
Rouslan: If we build this, will you start using this?
mweksler: This is one of the
things that the team that evaluated PR API were looking at as a
key benefit
... if they had had this feature they would have used it
Alex: One of the biggest
priorities is the guest checkout experience
... The high priority is getting the payment and signup
done
... once the user has paid and has an active reservation, it's
easier to ask the user to provide data
... but if you have to get all the data in advance, it's less
likely the user will complete the reservation
Giulio: With Apple Pay we are big
fans of guest checkout
... we have several implementations that can accomplish this
goal.
... get the payment and then use the info to create an
account
... the big question is what's the data: password?
birthday?
... there are several examples of this sort of thing being
done
... we have some examples where at end of payment a "silent
account" was created without a password
... but we've moved away from that.
... for a while the approach was to add a password after the
payment. ... but now we are moving toward "sign in with
apple"
Marcos: For Airbnb you may need
to send passport photo.
... at some point we are going to end up at just another
browser tab
... I am concerned that payment handlers become too heavy....we
have APIs to achieve some of these things already
... do we just need an overlay browser context for payment
handlers?
... we want to be able to do logins on the Web....I think we
all want to solve that problem
NickTR: Dinner at 7pm. Thanks everyone for concentration today!
We adjourned until Tuesday.
[Slides from Ian and Lawrence on pain points]
Ian: Our first session this morning comes
after a suggestion from Lawrence Cheng who wanted us to ground our work in real-world pain points.
... We have collated information about both consumer and
merchant painpoints
... Later we will run some mini-breakouts to evaluate the importance and difficulty of addressing some of these pain points.
[Slide - painpoints at checkout]
Ian: I put this slide on painpoints a checkout first since it is most closely related to Payment Request API. As you can see, I think we are doing a good job at addressing many of these points
Lawrence: I am sure we can add to these. We should look at these
with a "pinch of salt"
... and what is the wider context
... and does payment request address these?
Ian: Would be great to collate more point points from the group (invites colleagues to contribute via IRC)
Vincent: shipping options/addresses for smaller countries are often not well provided for
[Slide - trust, security and privacy]
Ian: We may not be able to do so much on these topics in this group, although some work in other groups could help (e.g., related to trust, privacy).
vkuntz: the bigger online sellers
are not present in Belgium (for example) and do not ship
there
... but often the consumer doesn't know about this until the end
of checkout. Another pain point to consider: shipping location not indicated upfront - shipping actually not
possible to a specific country
rouslan: vkuntz's use case is
very interesting
... I would probably start by geo-locating the IP address of
the consumer and display a warning
ciciley: what does best practice look like with payment request?
Ian: we have some developer documentation but happy to add that to the list
<AdrianHB> [group takes moment to pat itself on the back]
ian: next we look at merchant painpoints
[back to slides - payments and checkout]
ian: redirection to hosted payment page is called out as poor user experience
vishal-expedia: how does Payment Request deal with the hosted payment page challenge?
ian: payment handlers solve for this. User doesn't lose the merchant context
Vishal-Expedia: what about 3DS 2.x?
ian: the security task force is looking at this - in short it's tackled by the improved experience of handler
rouslan: payment handler is treated like a full page redirect but appears as an overlay
Ciciley: the other pain point is
that stronger authentication negatively affects approval
rates
... most merchants are frustrated about why transactions are
being declined (cards)
jonathan: the point of 3DS2 is to
provide better scores to the issuer but this information may
not be known to the merchant
... so the expectation is that approval rates should
improve
benoit: Login while
traveling a pain point. I think Ian's attempt at a demo (but that rendered in Japanese) showed a
good pain point - localisation which might not be
appropriate
... but also if the issuer doesn't step up the authentication
and then declines the subsequent transaction then that really sucks
ian: on trust/security, payment handler attempts to reduce the complexity/cost of providing more secure experiences
lawrence: on security, I think
the key is "that work for customers"
... also would be good to talk about firendly fraud
Ciciley: Lawrence, I was queued
up to talk about friendly fraud.
... I think it's appropriate for this group to figure out
during auth to figure out it's the "parent not the child"
... where issuer thinks parent authorized a transaction, then
the bank is liable and they'd like to reduce that
... too many Fortnite purchases.
... that's another step in the right direction....ensuring the
right person is authorizing the transaction.
<html5cat> What is "friendly fraud"?
NickTR: People would be shocked
at the size of the friendly fraud problem, e.g., on the order
or 40%
... or "buyer regret"
... Many children can unlock their parents' phones
... I think it's something that would be hard for us to
tackle.
... I note also that some payment mechanisms (non-card) do not
include chargeback mechanisms
Jonathan: I think the use of
WebAuthn and biometrics helps a lot
... the problem we have with device biometrics is that there is
no way to link to a specific individual
... if there were a way for a given transaction to have more
specific authentication, that could be interesting
<benoit> unlocking a device and authenticating payment should be different things
lawrence: if we could crack some
of these points, then we could give ourselves a real leg-up in
getting merchant adoption
... so the question is do we see any unique selling points ("USPs") in payment
request
ian: for our webauthn colleagues in the room, are you looking at this issue of more personalised ID?
John Bradley: it's something we've looked at - many platforms are missing the ability
<Ian> (IJ hears: "segmenting biometric templates" raises usability issues)
John Bradley: we may end up with a system that is too complex for consumers to use
xxxx: it's the individualistic biometrics that are difficult
John Bradley: you could have separate hardware tokens for different users. Once you have multiple templates on a single device, it gets very difficult to understand and it's difficult to design biometric systems which are not defeatable
vishal: it's not just kids - also criminals forcing users to biometrically authenticate
<Ian> Vishal: Netflix does this well - ok to have friction to set up new profile
<Ian> ...they ensure there's a kids profile
<Ian> Jonathan: You can have different profiles, but the same biometrics can access the profiles
<Ian> John Bradley: On newest Android, and where not blocked by carriers, templates are available
<Ian> benoit: Multiple profiles on the phone is a good concept but agree with usability challenge
<Ian> ...I think the real solution to this (but not necessarily for this WG)....I could set up a flag on a biometric "this fingerprint cannot be used to authorized payments"
<Ian> dezell: Some pain points for us at Conexxus (for physical world payments): EMV at the pump; second generation EMV. +1 for better granularity of control of permissions granted to specific biometrics (but consumers are unlikely to set up). SRC seems ok but Conexxus members still waiting to see how works with PR API
<jonathan> +1 for better granularity as well
<Ian> dezell: Anticipate more remote payments (e.g., barcode based payments). Merchants need more consumer data; but GPDR and and California rules make it challenging
ian: back to the slides
... integration is complex - we heard yesterday from AirBnB
that it would be great to do more (like sign up) with PR
[rules and regulations]
ian: we have a lot of items on
our backlog for shipping
... but we have not looked (to date) at a lot of new features
because the consensus was to finish v1 first
... let's organise into 4 groups and prioritise this list of 16
pain points
html5cat: at Puma browser, we would like to see if our browser could be helpful for some of these painpoints - we are not bound by the incumbent user bases of the big browsers. We can innovate quickly.
<rouslan> +1
[Breakouts on pain points]
We listed the following pain points for discussion:
<Ian> Images of importance/difficulty discussions
AdrianHB: We thought everything
was important
... a common theme was that a lot of pain points could be
addressed through more widespread use of payment handlers
Lawrence: For global players,
simplifying cross-border important and difficult
... for local merchants that do export today, there are not a
lot of options for them to do cross-border payments and it can
be expensive
... at the same time, we have situation with wallet players for
cross-border payments....the volumes are quite low (e.g.,
Chinese tourists using Apple Pay today)
... the other one I want to point out is "optimal speed for
checkout"...not too fast/too slow
... for new-to-merchant consumers we thought it was important
but somewhat difficult
... but for returning customers, as important but not as
difficult
Ian: We also talked about not too fast/not too slow
Lawrence: We observed our goal
ultimately is imperative conversion and reduce
chargebacks.
... to be able to tick the box that we have succeeded we need
to be able to show scale
Rouslan: We had some challenge
figuring out who this was related to (difficult for whom?
important to whom?)
... maybe privacy would be super important to users if more was
communicated to them.
... on the other hand, in terms of difficulty, some things may
be difficult for PSPs today, but some things might be shifted
to UAs through web payments
... our process was first to figure out what was important,
then we assigned difficulty
Ian: We did that as well.
Rouslan:
We had some confusion
around "account-free checkout"
... who is the account with?
... I think the most difficult things to figure out are things
that are product challenges (moreso than engineering
challenges)
... so reduce auth friction and speed up checkout...those are
great...it requires a lot of experimentation and user studies
to do this well
... so it's actually quite challenging to do in practice
Ian: Next steps - four of us synthesize and report back
[Ian's slides on Rechartering]
<Zakim> vkuntz_, you wanted to note that Credit Transfers will probably become more relevant with PSD2 in Europe
<nicktr> Lawrence: can we have a table showing the possible and actual combinations of browsers and payment methods?
<nicktr> Rouslan: Chrome's position is to support as many options as possible
<nicktr> ...so we'd like to see no tie-in between handler and browser
<nicktr> ...though that isn't the current reality
rouslan: Payment handlers can
help localize the user experience; there's now way that a
browser is going to adapt to all the local requirements
... so payment handlers are the future. Basic card
isn't really implemented anywhere but Chrome. We can probably stop
actively working on Basic Card.
marcosc: We think that basic card
is "worth it" but it's challenging to do well; we had about 10
people working on it
... if anyone out there wants to be the Basic Card provider for
Firefox, contact me!
... I agree that having multiple payment handlers would be
ideal
... Firefox would need resources to do and maintain Basic Card.
Gerhard: I think Basic Card is
useful.
... regarding SRC subsuming 3DS and tokenization
... all three of them are "optional" and "interoperable" but
need not be used all together
... it's important for me and I think the industry that with PR
API that the flexibility be maintained
... I agree that the 3 together would be a beautiful symphony,
but don't assume merchants will demand to use all three of
them.
Jungkee: I agree with how Ian
captured the spec status in Edge.
... we support the idea of supporting multiple payment
handlers. We don't have any plans to disable any payment
handlers.
... regarding Basic Card, Edge already supports it.
... I see no reason to stop working on Basic Card
... It's an ongoing discussion with MS about relationship to MS
Wallet; but I don't have any updates about MS Pay
... So we'd like to figure out how to further promote PR
API
... including more communication with customers, merchants,
partners
... are there good ways to approach merchants let's discuss
dongwoo: Here's a status update
from Samsung - we also support Basic Card in Samsung Internet
browser.
... so I think Basic Card remains useful and we should at least
maintain this as a solution
... Samsung Pay also works on Android.
... and we're happy to work with other browsers and other
collaborations with payment handlers
benoit: Will SRC be required for all issuing banks? If the answer is no, then we need another payment method for other cards the are issued
Jonathan: SRC does not require tokens
[Question about whether SRC would ultimately subsume Basic Card]
benoit: We can't eliminate Basic Card unless we have a replacement that meets the requirements.
JonathanG: Could you list the requirements you have in mind?
jv: The basic premise is we need
a minimal level of interop; card payments (basic) are the de
facto. Seems Basic Card is basically done (but for
Safari).
... we need something that works "most of the time" otherwise
PR API won't be adopted.
... 3DS is no longer really optional (cf Europe)
... tokens are not that hard to do, so I think they will be
increasingly used as a trinity
<rouslan> +1
<Zakim> AdrianHB, you wanted to distinguish between basic-card and the need for basic-card handler built into browsers
AdrianHB: I think it's important
to make the following distinction -merchants should be
able to get card details back, but that doesn't necessarily
mean that the card details need to be returned by the
browser. Today Basic Card is
basically replacing autofill....in my opinion, that's the
sticking point for the moment
... I think it's useful to distinguish the simple ability to
return card details, but can we change how that's implemented
today?
<estes> I agree with AdrianHB. We didn't see basic card built into safari as a meaningful improvement over autofill and thought it could introduce user confusion to show a payment sheet that might look like Apple Pay but not offer its security benefits
justin: Chrome ships with an
implementation of basic card. There could be third parties that
are willing to support basic card (think "Firefox")
... if the browsers are not building support, are there
third-party payment handlers willing to step up to support the
payment method?
... we had a lot of conversation yesterday about 3DS....I also
challenge the assumption that it's covered by SRC.
... I think there's some more thinking to do on that
nicktr: As much as I'd like to see Basic Card go away (due to security challenges), the reality is that we need to have basic card
<jv> +1 Keep 3DS/Authentication separate from SRC
nicktr: so I think it's difficult
for merchants to see the benefit of implementing PR API
... because there is not a single payment method supported
across all browsers, that's a key disincentive to
adoption
... if I could pick one key thing in rechartering, it would be
to have one payment method that works across browsers.
Ciciley: There are some payment brands that have landed support for some aspects of SRC
Vishal-Expedia: We've been having
SRC conversations for 1 year. There are some use cases within
Expedia where Basic Card is absolutely required
... so not having Basic Card would mean we would not adopt PR
API
... I think you need to ask 100 merchants for their views on
the importance of Basic Card
Gerhard: Maybe the answer is to
extend Basic Card to support an e-commerce token (that
merchants are being required to accept)
... perhaps useful for merchants to reduce PCI burden via
e-commerce token
Tomasz: What else would we add to Basic Card? We could stop work on Basic Card and it could still be used by the industry.
<nicktr> I'd like to suggest that the security task force looks at Gerhard's suggestion - we were looking at "tokenized" payments before SRC came along. Can we support both?
Rouslan: We are not really talking about killing Basic Card, just no longer working on the spec.
AdrianHB: If we are going to
fully embrace payment handlers, shouldn't basic card support be
more like other payment handlers?
... I have some slides for after lunch
<AdrianHB> ian: one question to consider, are there other payment methods we need to consider
<AdrianHB> ... prioritization of future work
<AdrianHB> ... we have developed good liasons with FIDO and EMVCo, are there others?
<AdrianHB> ... we also need to think about how long the new charter should last
<AdrianHB> [STRAWPOLL] Any objections to recharting?
<AdrianHB> - None
<AdrianHB> ian: next steps is for chairs to draft proposed new charter
Gerhard: Yesterday we say a presentation on QR codes. EMVCo has a standard. We are seeing more demand for it. Should we explore QR codes in our charter?
<AdrianHB> +1
<michelweksler> +1 for QR
<nicktr> +1 for QR
Ian: Could auto-fill plug into PR API requests for Basic Card
Justin: Some issues around user-consent in that model
Rouslan: For
auto-fill-to-basic-card...something even more interesting than
that is flowing in the other direction...
... data flows from basic card payment handler to auto-fill
fields
... so the merchant doesn't need to use PR API, but Payment
Handlers are still useful to users.
AdrianHB: We've had at least one
example of a 3rd party payment handler that did Basic Card
(this was Klarna)
... are there others who might explore that if Basic Card were
the ubiquitous option?
<Gerhard> +1
Ian: (I recall the value proposition was riding basic card rails without requiring any changes to merchant site.)
Ian: So next steps is for the Chairs to come up with a draft charter based on your comments and other data from this meeting
Apple sent email prioritizing feature requests for Payment Request 1.1 based on previous discussions. These notes were included in the minutes after the meeting:
AdrianHB: This is just a quick-ee
intro; we can go listen to Stefan across the hall for more in
30 mins
... a site that wants to accept streaming micropayments puts a
<meta> tag in their site
... the content of the tag is a URL that is a payment
pointer
... the way that the protocol works is that the browser fetches
the document at that URL
... the browser generates a session header (unique)
... when payments are sent to the address, the address is
slightly different for each session
... to avoid correlation
... the Web
Monetization spec under discussion in the WICG defines a monetization object. An event fires every
time a payment is sent by the browser
... in terms of sending the payments, Coil has implemented this
as a browser plug-in; Puma browser has implemented this natively
... what we are looking for is a new payment method called
"monetization"
... and implicitly there is no user interaction; there is
assumed some pre-authorization of an amount
... and as the user browsers small amounts of value are
transmitted
... a "web monetization agent" is a component in the browser
that makes decisions on the user's behalf about how much to
spend on each site
... users need to be able to control their ability to pay on
certain sites.
... a core requirement is privacy - how do we build a
client-side component that evaluates how much to pay and how
much, but without becoming a tool for parties to track
users?
... the monetization agent is authorized to make payments out
of the user's wallet (which may be the same or different party
from the party that distributes the monetization agent)
... that is: we've decoupled monetization agent from wallet (source of funds).
... e.g., use Coil's web monetization agent but pay via google
pay
<Zakim> rouslan, you wanted to ask whether the web has any other progress type events
Rouslan: This is an interesting
idea. A "progress" type event might be tricky to
implement
... Marcos, do you know of any progress-type events?
marcosc: There is a Progress indicator element that has one
AdrianHB: We have been thinking about this as a streaming protocol
<marcosc> rouslan, e.g., progress event from XHR https://xhr.spec.whatwg.org/#interface-progressevent
AdrianHB: On 16 September we
(Coil) announced a "Grant for the Web." We've set aside funds
for grants to people who are developing content to push this
ecosystem forward.
... joint announcement with Mozilla and Creative Commons
... the overlap with the WPWG is:
* Definition of a monetization payment method
* Role of payment handlers
AdrianHB: one idea is web site
calls PR API (instead of "meta") and payment handlers
respond
... there are breakouts tomorrow on this topic
IJ: Describe user flow?
AdrianHB: I have money in a
wallet. I get an authorization from that wallet in the form of
an access token. I give that to the monetization agent.
... I leave it up to that agent to make decisions about how to
pay for content
IJ: What is payment request role?
AdrianHB: Potentially the merchant could use it to invoke web monetization, but without user interaction
IJ: That would require a change to PR API that requires a user gesture
Marcosc: I encourage people to check it out
[The crowd chants for demo!]
AdrianHB: It's up to each site to
figure out how they reward the monetization offer
... e.g., in the game demo we just looked at, the game provider offers free
coins. Somebody else might, say, not show ads.
Rouslan: Web Monetization based on ILP?
AdrianHB: Yes.
... The way we've done the payments rails is using ILP
... ILP let's us set up an addressing space.
... it's easy for us as Coil to route payments that way
... it's not a payment network per se...just an addressing
overlay on existing payment systems
Rouslan: Is that a hard dependency on ILP?
AdrianHB: In theory no, but yes practically. There is no other way that is cost-effective for sending such small payments
Rouslan: Is Interledger being done at W3C?
AdrianHB: Work started at the W3C
Interledger CG. There is now an Interledger Foundation. The
intent is for all the IP to be held by that organization, and
to stay open and RF
... the IETF draft on Interledger
is not standards track
... we've not taken anything on a formal standards track
... these are community-developed documents.
agektmr: What is relation to Metamask?
AdrianHB: There are quite a few
efforts to do this with cryptocurrencies.
... if the hard dependency on crypto rather than ILP, that will
be the end of the game for them
... until things are built into browsers, it's not going to
take off
... if they were to do payments with payment systems we already
use, they would be more successful
Tony: The Web Authentication
Working Group is working on WebAuthn2.
Also, we'd like to understand better payment handlers.
... Web Authentication WG is rechartering through 2021
... some level 2 features include:
Tony: We have deployment of
WebAuthn1 in Chrome, Edge, Firefox. In development in Safari
(desktop)
... we'd like for payment handlers to be able to use
WebAuthn
... we don't have delegation yet
... it takes place between the relying party (the handler) and
the client (the browser)
...We'd like to understand
your requirements for authentication beyond the payment handler
itself
marcosc: We have a payment sheet that operates as a top-level browsing context.
AdrianHB: We still need to cover delegation
Tomasz: In the context of 3DS
2.0, there is a challenge flow that is sometimes implemented as
an iframe.
... it's not possible for the issuer to perform 3DS step-up
without an iframe
Tony: I had pointed to pull request 911. The group had wanted to go
down the feature policy path; there were objections and we are
trying to work through them
... I think it's just feature policy itself.
Jonathan: There are a few things we discussed yesterday..."delegation" is one
Tony: We want to understand your
use case and determine the best approach.
... I have the feeling there are use cases where you'd like to
carry authentication downstream.
Jonathan: Someone who is not the
relying party wants access to FIDO credentials and return the
signature back to relying party
... a second use case is something to facilitate 3DS where the
issuer has created credentials and the merchants would like to
use them
Tony: There is some information we've agreed to with EMVCo about what information will be passed along [to 3DS]
Jonathan: In that case, the
relying party is still the merchant. But there are use cases
where the relying party is not the merchant.
... this morning we also discussed that it would be nice to
distinguish from among users (that sort of support
for multiple profiles is more of a FIDO or platform
thing).
Tony: Agree that's a platform question.
JohnBradley: As mentioned earlier, profiles raise usability issues
Tony: if the wallet is doing
the WebAuthn directly on the device, there is no concept
currently of segmentation of the use of the credential.
... it's easy to say "the wallet could do it" but then we'd
have to have different enrollments all the way back up
... the complexity goes up when building up all the things
around it
Jonathan: I had in mind that the relying party at enrollment time could create some new things (e.g., templates)
JohnBradley: That's theoretically possible but the infrastructure parts may not be able to handle the segmentation
Jonathan: Yesterday we also spoke
about the use case where the relying party wants to know what
key ids belong to it.
... is that something that is standardized?
JohnBradley: It's standardized so that the relying party can never know that.
Jonathan: Even if the relying party created the keys?
JohnBradley: We can't create a
super cookie that can be returned without user consent
... if you want to create a cookie to memorize credentials, you
can just do that.
Jonathan: Is there a privacy issue to know what authenticators are on the platform?
JohnBradley: Yes
... There is at least one person on this side of the table who
has concerns about adding to browser fingerprinting.
Jonathan: You would like to know whether there is an authenticator on the platform.
JohnBradley: You can learn "there is an authenticator" and for some platforms you know what that is, but you cannot find out what biometrics are supported by that authenticator
Tony: You can ask for user verification, but you can't ask for implementation of that
Gerhard: I want to touch on 2
edges of the spectrum
... one things mentioned in SCA is secure display
... right now there are 2 levels: user presence, 2 factor
... but there's missing a third level - secure display
... it would be great to combine "secure display" with getting
biometric
JohnBradley: That's defined by
the spec but supported in no browsers or
authenticators...there's no support by browsers
... the counter-proposal would be to have something that is
more generally deployable
... nothing in SCA says the secure display has to be part of
the authenticator itself
... but I would argue if your browser is compromised you have
bigger problems.
... so in WebAuthn we could have info from the payment handler
signed as part of the client data
... I think we could meet SCA requirements across all browsers
with existing authenticators...signing the payment handler
output in client data
Gerhard: That is the open banking
scenario; you may have registered 5 authenticators and the
calling party (the "AISP") might have to reach out to all five,
and all five might decide to do their token step-up and that
would be a bad UX
... so any way to passively sign to give a lower risk indicator
and defer step-up; that would be useful.
JohnBradley: Silent signatures from relying parties raise the same fingerprinting concerns
Gerhard: I'd like to say "If I can prove who I am ..."
JohnBradley: Should be able to
use cookie
... token binding comes to mind here
Tony: You could do something through cached credentials (somewhat how UAF does this today)
JohnBradley: It would be an interesting privacy discussion
Gerhard: Many rules are based on risk assessments. If I can get more proof of who the person is, I can have less friction, and less abandonment.
JohnBradley: Token binding
intended to fulfill that...but token binding is on hold as
Google and MS work out issues.
... You can use token binding to ensure a cookie cannot be
exfiltrated from browser.
Tony: I propose that we have a
task force between our two WGs
... to ensure that we have the use cases and we do the
flows
... and that can be brought back to the WG for discussion
NickTR: My use case builds on
Gerhard's....you were describing account aggregation
... my vision of payment handlers in the credit transfer space
is very similar
... imagine you have a payment handler that is aware of the
user's different current accounts with different banks.
... in principle there's a use case where you authenticate once
to the payment handler, and you don't have to re-authenticate
for each bank account.
... if you read the primary legislation (PSD2), it's the bank's
responsibility, but that could be delegated (to the payment
handler)
... so the payment handler should be able to pass auth
credentials to a bank without more user interaction
... nobody is going to use a flow with multiple
authentications
... I'd love to dive into this use case (even if hard)
Jonathan: There is a distinction
between "delegation" and "delegation." :)
... e.g., the bank could delegate to the merchant or payment
handler who is the relying party
... but the second meaning of delegation is that the relying
party is the issuer itself
... so you registered with the issuer, and then in another
context the bank says "I allow you to use my credentials";
that's a different form of delegation...the bank still owns the
credentials, but they provide them to someone else who can
return something to the bank
JohnBradley: We are considering
the latter form of delegation
... the iframe could be invisible.
... you could do an invisible iframe to the bank and using post
message and a protocol between merchant and bank for
credentials
... that has some good privacy properties
... essentially if you allow the second model you enable
correlated identifier that may be a backdoor tracking
mechanism
... we want to figure out how to give equivalent functionality
with privacy
NickTR: In my use case, nothing goes back to the merchant
JohnBradley: Replace "merchant"
here with "wallet provider"; same issue
... if I had multiple merchants and multiple wallets and they
all used the same credentials they could correlate.
AdrianHB: Raise your hand if you want to be part of the joint task force: Gerhard Oosthuizen, Nick Telford-Reed, Jonathan Grossar, Tomasz Blachowitz, Gildas Le Louarn
<scribe> ACTION: Tony to convene a joint task force on payment use cases that involve Web Authentication
[Slides by AdrianHB with ideas for handling payments]
AdrianHB: The context for my
slides here come from a conversation yesterday where Marcos
expressed concern that a lot was going into payment handlers
that would make it harder for new implementations to catch
up
...First observation is
that Basic Card does not fit well with other things...in sheets
there's a mix of payment handlers (wallets) and cards
(instruments)
... but delegation of merchant-requested data to the payment
handler changes the game
... payment handlers should be able to respond to the
merchant's request
... this means that payment handlers end up doing everything
done by the sheet
... so the question is: do we need the payment sheet?
... The sheet requires an
extra click
... the payment sheet has been a blocker for implementation in
some browsers
... we've heard from all the browsers that implementing the
payment sheet is outside their wheelhouse in terms of
localization and because payments are not really the things of
browser
... so what would it look like to ditch the sheet?
... I found some examples of how the Share API works
...When I hit "pay" I
could get a list of payment handlers I could use
... we could have a number of optimizations like
"skip-the-sheet"
Lawrence: How could a payment handler get in the list?
AdrianHB: Through registration
via payment handler API
... Instead of getting mix of instruments and wallets in the sheet, you just
see wallets [in some type of selector UI]
... Today the payment handler API has a registration flow.
Service worker installed. This enables the browser to get a
manifest and the browser can do just-in-time install
... As Ian said, how it happens is platform-specific.
Rouslan: Great idea. I think one
comment rubbed me the wrong way - that payment handlers are
becoming Frankenstein.
... the payment handler is just trying to bring all the options
in PR API to Payment Handlers
... we are experimenting.
... overall as an idea that the sheet should go away...I think
it could be strange for w3c to dictate UI...but I think it's an
interesting idea.
marcosc: I want to support what
Rouslan said but wants to shift the perspective.
... PR API on its own and integration with native payment
handlers makes a lot of sense
... but what was shown yesterday was that the handler modal was
not suitable for some UI requirements.
... so it's becoming like an embedded iframe
... and Airbnb wants to enroll users, too
... so we end up with a component that can be co-opted to do a
lot of things
... so let's not get rid of the sheet, but instead have a model
browsing context that let's you do all these things
... we just need a bi-directional channel
AdrianHB: One of the things that
came out of the discussion is that we've built a payments
component that is using a lot of web features, but in a way
that is only usable in those flows
... the modal window (of chrome) is special
... I think the modal window is a powerful feature for any
cross-origin thing you want to do
... I think it's a valuable platform in general, and it makes
the case for building blocks for payment handlers much
stronger.
... I'll call this the "modal dialog" feature
<marcosc> "modal browsing context" - fight me
AdrianHB: You could not have popup abuse since only one at a time, and also you only get back to underlying context when you close it
roy: My main comment on that is,
one value proposition of the payment sheet is that there's a
level of trust
... I trust the browser vendors to do the right thing with that
dialog.
<Zakim> nicktr, you wanted to ask about security model. Does this rely still on the method manifest?
nicktr: My question is similar - and payment handlers have a payment method manifest
marcosc: We are showing arbitrary
content in something that people thing is secure, but it's
not
... we won't present a trusted UI where there is arbitrary
content.
<scribe> ACTION: AdrianHB to look into a modal dialog spec, organize testing of assumptions about dropping the sheet.
AdrianHB: Some other ideas: drop instruments, drop modifiers, drop OpenWindow
<marcosc> Today, in order to do certain forms of authentication on the web we require either pop-ups, opening a new tab, a redirect, and so on... Payments introduced another UI component that affords OS-level payment integration (particularly for Apple Pay in Safari). When compared to native applications, most of these UI affordances lead to sub-optimal user experiences.
<marcosc> To improve the situation, a common requirement appears to be:
<marcosc> - a top-level browsing context that displays third party content.
<marcosc> - it's modal.
<marcosc> - it should be possible to position this browsing context at least relative to the top or bottom of the container window, and perhaps have the ability to visually expand the context (or let the user expand it) - and the ability to go fullscreen. The browsing context (not the opener) controls the dimensions.
<marcosc> - the opener context needs to set the feature policy (e.g., allow web authn, camera access, credential management).
<marcosc> - the opener context must a means to have by bi-directional communication channel (i.e., message ports or just post message).
<marcosc> - the opener context must have the ability to close the browsing context.
<marcosc> - an ability to indicate the kind of service that's needed (e.g., "payment", "authentication", "share", "mixed?")
<marcosc> - An ability to open a pop-up (normal pop-up rules apply) - but associated with the browsing context... basically a less crappy tab experience on mobile.
Ian: With chairs we need to
review the dense minutes
... I assume we will recharter so next meeting discussion
assumes that
NickTR: Remember when we recharter - your AC reps need to step up to say Please Recharter!
Alex: Airbnb could host the next meeting, e.g., in Dublin or Paris
NickTR: +1 to Dublin
<scribe> ACTION: NIckTR to investigate next FTF meeting options with Ian and Adrian
Ian: Minutes available next week
NickTR: Do people read minutes?
[Several people say yes]
NickTR: As Chair it's good to
understand what improvements you think we could make in running
the group. E.g., who needs to be part of the discussion? We
heard yesterday: PayPal, Alipay, WeChatPay
... so we'll work on that.
Rouslan: I think once useful thing at each TPAC is to give a clearer picture of where we are with deployment. So I think some framing would be useful.
NickTR: Maybe we need to start main meeting at 10:00am on day one, and have a crash course before that.
Gerhard: Or do a video
Ian: I collect links to videos on our PR API introduction page.
<jv> Invite UPI from india, and OpenBanking UK we need to get more wallets, perhaps from Nordics where they are quite big too. Then south america, boleto.
IJ: Another idea is a merchant business group.
+1 from Frank
NickTR: Jeff Jaffe also mentioned
a series of meetups (with merchants)
... could do them around other events like MRC
Vishal: Another conf is Payments Ed
David: Have we done anything about consumer involvement (e.g., for the UX)?
Ian: Implementers do user testing. But we could have a big show-off-a-thon with lots of users and multiple browser vendors to get feedabck
rouslan: Perhaps what we are looking for is a user experience expert. Some people in the room have "user experience experience." But we could bring UX experts (e.g., from Google) into a meeting to speak about how they think about those things
Justin: I generally agree with
Ian that browser vendors and other implementers are on the
front line of UX
... I think it could be useful to have them before the group
here to point out how difficult it is.
NickTR: We are facing a problem standards efforts share: companies need things to work together but also want to maintain some advantage
Vishal: We user Applause for anonymous user testing.
Alex: We use applause as well
<scribe> ACTION: Jeremy to see whether Stripe could provide any data about PR API
Ian: Next scheduled teleconference is 3 October. Stay tuned for details.
[Adjourned]
