14:49:09 RRSAgent has joined #wpwg 14:49:13 logging to https://www.w3.org/2025/01/30-wpwg-irc 14:49:17 Meeting; Web Payments Working Group 14:49:22 Meeting: Web Payments Working Group 14:49:28 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20250130 14:49:30 Chair: Ian 14:49:32 Scribe: Ian 14:49:38 regrets+ Nick_Telford-Reed 14:49:44 agenda? 14:49:51 agenda+ Secure Payment Authentication (SPA) 14:49:56 agenda+ Payment Links 14:50:00 agenda+ Digital Wallets 14:50:03 agenda+ Next call 14:50:08 agenda? 14:53:01 TallTed has joined #wpwg 14:58:25 vasilii has joined #wpwg 15:00:17 present+ Sami_Tikkala 15:00:19 present+ 15:00:25 present+ Hemen_Chhatbar 15:00:25 JL has joined #WPWG 15:00:28 present+ Kenneth_Diaz 15:00:32 present+ Jean-Luc_di_Manno 15:00:36 present+ Arman_Aygen 15:00:39 present_ 15:00:39 present+ Fahad_Saleem 15:00:46 present+ Jon_Southall 15:00:46 present+ 15:00:54 KennethEntersekt has joined #wpwg 15:00:55 present+ Vasilii_Trofimchuk 15:00:58 jpm-block has joined #wpwg 15:01:07 present+ Jean-Pablo_Marzetti 15:01:09 present+ Gustavo_Koik 15:01:14 present+ Ioana_Chiorean 15:01:20 present+ Junhui_He 15:01:32 rrsagent, make minutes 15:01:33 I have made the request to generate https://www.w3.org/2025/01/30-wpwg-minutes.html Ian 15:02:29 present+ Jonathan_Grossar 15:02:30 present+ Doug_Fisher 15:02:36 present+ David_Benoit 15:02:41 present+ Alex_Lakatos 15:03:26 present+ Michael_Horne 15:03:52 zakim, take up item 1 15:03:52 agendum 1 -- Secure Payment Authentication (SPA) -- taken up [from Ian] 15:04:28 present+ Rouslan_Solomakhin 15:04:37 present+ Gerhard_Oosthuizen 15:04:47 Hemen: I am product manager of Google SPA. 15:05:00 present+ Stephen_McGruer 15:05:24 Hemen: Background to SPA is SCA to combat fraud (driven by PSD2) 15:07:01 ...but UX in 3DS has been inconsistent 15:07:28 ...52s average time to complete 3DS2 challenge with 20% abandonment rate 15:07:50 ...leading to lost sales from SCA challenges (in the billions). 15:08:06 ...so we've come up with Secure Payment Authentication to reduce friction and meet SCA / dynamic linking requirements 15:08:47 [We walk through UX] 15:09:20 Hemen : When the user clicks on "pay", the merchant or PSP checks to see whether SPA is available. 15:09:35 ..the user is redirected from the merchant site to the Google site. 15:09:53 ...the user can choose to authenticate to Google or "another way" 15:10:06 ...if they choose google, there is a biometric authentication. 15:10:25 ...we send a payload back to merchant/PSP and the transaction is sent back for authorization 15:10:28 present+ Kavya 15:10:31 present+ Praveena 15:11:04 Hemen: In our V2 UX we made the experience more consistent with Google autofill / Google pay experience. 15:11:21 ...the user clicks on "pay now" and sees a transaction dialog. The user can choose to verify now or another way. 15:11:41 ...the V2 experience improves performance over V1 15:11:51 [We talk about how it works under the hood] 15:12:11 Hemen: When the user chooses a card on the merchant site, the PSP calls SPA to initiate authentication 15:12:31 ....they send over the PAN to google. We map this to a device-bound token on our end. 15:13:03 ...we have a token and cryptogram which satisfies SCA 15:13:45 ...the token is created after 1-time bank authentication, and the token only exists in this device. Meets regulatory requirements 15:14:06 ...so we replace the card with an existing token provisioned on the device. 15:14:12 present+ Melissa_Sebastian 15:14:20 [Benefits] 15:14:34 Hemen: We've run this for over 1 year and seen these benefits: 15:14:44 * strong verified payment credentials with 2FA and liability shift 15:14:51 * Higher authentication rates and authorization rates 15:14:54 * Improved UX 15:15:02 * Improved user satisfaction and user retention 15:16:10 Hemen: 9 out of 10 users choose to verify with SPA when presented a choice. 15:16:51 ...we've found SPA faster (30%), with +5pp uplift in authentication and +3pp uplift in conversion 15:16:57 ...those numbers are based on V1 of SPA 15:17:04 q+ 15:18:03 q+q+ 15:18:16 queue= Jean-Luc, Ian 15:18:23 q+ 15:18:55 Gerhard has joined #wpwg 15:18:57 gkok has joined #wpwg 15:19:11 q? 15:19:14 q? 15:19:16 q 15:19:50 q+ 15:20:01 q+ 15:20:02 Ian: Have you considered SPC as a backup when tokenization has not happened? 15:20:18 Hemen: We have been chatting with the Chrome Team 15:20:31 ...there are some differences and some similarities. We are looking at how to marry the best parts. 15:20:52 ack Jean- 15:21:04 Jean-Luc: I have three questions 15:21:47 ...you keep mapping with device token. How do you manage privacy of mapping of PAN to token? 15:21:59 ...what if there is no device token when SPA called? 15:22:16 ...is this available on laptops? 15:22:25 ack me 15:23:06 Hemen: We check for device token on device. For privacy, there is some fuzzy matching. 15:23:33 ..for fallback, we don't have an inline tokenization flow. 15:23:51 ...it's up to the merchant and PSP to determine amount of friction they want 15:24:19 ...we optimize for "existing token" case and otherwise leave decision to merchant 15:24:40 Hemen: At the moment SPA is android for now; we are looking into hybrid flows 15:24:47 ..or laptop-specific flows 15:24:55 present+ Roger_Matsui 15:24:58 q? 15:25:02 ack vas 15:25:40 present+ 15:25:43 vasilii: In 3DS we pass authentication value to issuers that auth has been successful. 15:26:03 ...this motivates them to approve transactions. In SPA what do you communicate to issuers and why should they trust that info? 15:27:01 Hemen: Device tokens and cryptograms have existed for a while. Google Pay uses these already. The cryptogram depends on the network integration. It might be on-device or over the network. These credentials have been issued by the issuer through the network. 15:27:08 ...these are the same tokens used for in-store payments. 15:27:22 ...so we are leveraging what already existed in a better UX 15:27:26 ack Gerhard 15:28:34 Gerhard: Have you checked your transaction dialog with EMVCo expectations? Could we use this flow for SPC? 15:29:00 ...with SPC we can achieve the same look and feel. 15:29:17 ...Stephen, what do you see in connection between SPC and SPA? 15:29:39 smcgruer_[EST]: From a technical perspective, SPA uses payment request API. 15:30:06 smcgruer_[EST]: SPA and Chrome are quite separate in that sense (compared to the browser implementing SPC as a payment method) 15:30:29 smcgruer_[EST]: The interesting part to me as well is that we can learn from each other. 15:30:52 ...SPA benefits from having a very trusted partnership (they are talking to parties in a trusted mode) whereas SPC has a very different trust model. 15:31:43 Gerhard: In both SPC and SPA there could be redirects (whether to Google or, e.g., for SPC a network) 15:32:14 Gerhard: How do you see this intersecting with digital identity / wallets 15:32:38 Hemen: We are in touch with our network partners to see how this could evolve into a more industry standard....Android folks have been looking at this 15:33:14 Gehard: Can this be used outside of Europe? 15:33:36 Heman: Technically it's not regionally restricted 15:33:41 q? 15:33:48 ack gk 15:34:25 gkok: In V2 is the requirement that the merchant be a native app? 15:34:38 Hemen: V2 supports not only chrome but Android apps (web views) 15:35:05 gkok: Can you have an experience where you don't redirect to google domain ? 15:35:29 Hemen: Going forward we expect a V2 experience (with the payment sheet). This should work with chrome and native apps 15:35:37 gkok: What is the main hurdle to expanding this? 15:35:58 Hemen: We don't see major hurdles. There is some integration cost (to achieve trust model) 15:36:06 ...we do see a lot of demand 15:37:17 zakim, take up next item 15:37:17 agendum 2 -- Payment Links -- taken up [from Ian] 15:37:39 -> https://github.com/WICG/paymentlink Support for Facilitated Payment link type in HTML 15:37:57 Junhui: We have some updates from our previous presentation of this topic. 15:38:09 ...reminder that this is to facilitate push payments 15:38:53 ...today the most popular push payment UX today is QR code (from desktop to get to payment service from app or site) 15:38:59 ...or on mobile-only to go from app to app 15:39:04 [Examples] 15:39:21 ...in PIX, payment code is generated by the merchant (EMVCo merchant-presented QR) 15:39:41 ...the user journey involves pasting a pix code in an app 15:39:52 ..it's a lengthy UX 15:40:32 ...In Maya payments (Philippines) example 15:40:49 ...still need mobile device to scan QR code 15:41:00 ...so the question is whether the browser can assist the user to improve the experience. 15:41:50 ...some questions: can android intents help? Issues: (a) android only and (b) requires active integration by merchant 15:42:09 ...payment request API could be used (but also requires active merchant integration and also a user activation is required 15:42:20 ..there are also UX implications in checkout page in PR API case 15:42:34 ...so we are exploring a more lightweight method 15:42:51 [Payment link proposal] 15:43:08 Junhui: merchant can easily put a element in their checkout page 15:43:21 ...we propose a new "rel" value of "facilitated-payment" 15:43:53 ...(we did not use rel=payment since that's already in use for other things) 15:44:03 ...advantage to our approach is that it's declarative (easy to add) 15:44:16 ...not as intrusive for existing checkout flows 15:44:53 [Junhui shows some example elements] 15:45:35 Junhui describes the user journe, where the user chooses a payment method, the payment client takes over the flow, and the user completes payment on the payment client. Afterwards, the merchant/PSP shows a payment confirmation page 15:45:46 [We look at the corresponding flow diagram and then some mockups] 15:46:58 Junhui: In the example, instead of scanning a QR code, the user can just authenticate in the payment client 15:47:04 [Status] 15:47:15 Junhui: We are currently prototyping in Chrome. 15:47:50 q+ 15:48:02 [Security considerations] 15:48:29 q+ 15:48:44 Junhui: Regarding risk of malicious attack, we think this is not worse than status quo (in terms of malicious actor modifying QR code or URL) 15:48:46 q+ 15:48:51 q+ 15:49:09 ..regarding safe browsing, we can use safe browsing tools to reduce abuse risk. 15:49:18 ...we are considering allow lists and signatures 15:49:46 -> https://github.com/WICG/paymentlink/issues/3 issue about custom URL schemes 15:51:05 q? 15:51:09 ack me 15:51:11 ack JL 15:51:54 Jean-Luc: How do you mean account-based payments? 15:52:01 ...does the bank authenticate the user? 15:52:52 Jean-Luc: How does this differ from payment handlers? 15:53:44 Junhui: This is easier to implement than PH API 15:54:25 Junhui: Regarding the account-based payments I'll defer to stephen. We need to think more about scalability. 15:55:47 smcgruer_[EST]: I view this approach as a different way to get at a conceptual payment handlers. 15:56:00 ...it doesn't mean we'll support payment handlers the same way we do today on day one. 15:56:24 ...this to me feels like a lighter way for the site to interact with a payment handler. This is declarative (not interactive) 15:56:40 ...so in terms of Jean-Luc's question about "what is being handled"...conceptually that remains up to the payment handler. 15:56:56 I have made the request to generate https://www.w3.org/2025/01/30-wpwg-minutes.html Ian 15:57:45 smcgruer_[EST]: There might be situations where payment handlers exist or don't yet exist. The browser can ignore situations where the user does not have an available handler, and the fallback can be however the user has paid in the past 15:58:07 Gerhard: We are working on defining a web link standard for defining QRs in another SDO 15:58:14 ...I will reach out to you 15:58:28 ...how is the browser parsing data to be able to display some info 15:59:26 smcgruer_[EST]: the goal of the payment link is to avoid having to parse QR codes 16:00:14 Gerhard: A user may have an intention to use an app. How does the popup get triggered? 16:00:31 q+ 16:00:34 Junhui: It's automatically displayed when we are parsing the DOM and find a payment link 16:00:37 ack Gerhard 16:00:39 q- 16:00:58 Gerhard: Is that modal a payment handler or google pay in a specialized window? 16:01:11 Junhui: It's a chrome component to choose a payment method 16:01:20 ..the final modal is controlled by Google pay 16:01:36 ...the user has to link a payment account to google pay 16:01:54 ack gk 16:02:31 gkok: I understand that the user had to onboard a wallet to google pay to tell the user that this payment method is available. I think this would not likely work with PIX because I don't think you can link PIX to a specific wallet. 16:02:45 ...if this being applicable to UPI, it seems like an interesting approach 16:03:04 gkok: I'd like to explore this more 16:03:32 https://support.google.com/googlepay/answer/14615541?hl=en 16:03:35 Junhui: I think that a PIX account can be linked to google pay. But we have a separate solution for PIX solutions. 16:03:51 ...for UPI I have not explored a lot yet. 16:04:52 RRSAGENT, make minutes 16:04:53 I have made the request to generate https://www.w3.org/2025/01/30-wpwg-minutes.html Ian 16:04:57 RRSAGENT, set logs public