Meeting minutes
Secure Payment Authentication (SPA)
Hemen: I am product manager of Google SPA. Background to SPA is SCA to combat fraud (driven by PSD2)
… but UX in 3DS has been inconsistent
… 52s average time to complete 3DS2 challenge with 20% abandonment rate
… leading to lost sales from SCA challenges (in the billions).
… so we've come up with Secure Payment Authentication to reduce friction and meet SCA / dynamic linking requirements
[We walk through UX]
Hemen: When the user clicks on "pay", the merchant or PSP checks to see whether SPA is available.
… the user is redirected from the merchant site to the Google site.
… the user can choose to authenticate to Google or "another way"
… if they choose google, there is a biometric authentication.
… we send a payload back to merchant/PSP and the transaction is sent back for authorization
Hemen: In our V2 UX we made the experience more consistent with Google autofill / Google pay experience.
… the user clicks on "pay now" and sees a transaction dialog. The user can choose to verify now or another way.
… the V2 experience improves performance over V1
[We talk about how it works under the hood]
Hemen: When the user chooses a card on the merchant site, the PSP calls SPA to initiate authentication
… they send over the PAN to google. We map this to a device-bound token on our end.
… we have a token and cryptogram which satisfies SCA
… the token is created after 1-time bank authentication, and the token only exists in this device. Meets regulatory requirements
… so we replace the card with an existing token provisioned on the device.
[Benefits]
Hemen: We've run this for over 1 year and seen these benefits:
* strong verified payment credentials with 2FA and liability shift
* Higher authentication rates and authorization rates
* Improved UX
* Improved user satisfaction and user retention
Hemen: 9 out of 10 users choose to verify with SPA when presented a choice.
… we've found SPA faster (30%), with +5pp uplift in authentication and +3pp uplift in conversion
… those numbers are based on V1 of SPA
Ian: SPC and SPA have similar transaction dialogs which makes me think that Google might see a benefit to unifying the UX for those APIs. Also, SPA captures one type of binding between account (represented by a token) and authentication credential (biometric authentication to Google). SPC is designed for integration a variety of protocols that support other types of binding (e.g., 3DS where the bank is the RP and knows the binding). It could be interesting to use SPC and SPA in tandem. For example, the user might not yet have a token on their Android phone and when the user clicks "pay" SPC is invoked to get credentials associated with an account from the RP (e.g., using 3DS). But later the user might add a card to Google Pay and SPA could be leveraged first (with SPC as a backup). It would be great from a UX perspective if the authentication experience were the same, no matter how the binding and communication happened under the hood.
Hemen: We have been chatting with the Chrome Team
… there are some differences and some similarities. We are looking at how to marry the best parts.
Jean-Luc: I have three questions
… you keep mapping with device token. How do you manage privacy of mapping of PAN to token?
… what if there is no device token when SPA called?
… is this available on laptops?
Hemen: We check for device token on device. For privacy, there is some fuzzy matching.
… for fallback, we don't have an inline tokenization flow.
… it's up to the merchant and PSP to determine amount of friction they want
… we optimize for "existing token" case and otherwise leave decision to merchant. At the moment SPA is android for now; we are looking into hybrid flows
… or laptop-specific flows
vasilii: In 3DS we pass authentication value to issuers that auth has been successful.
… this motivates them to approve transactions. In SPA what do you communicate to issuers and why should they trust that info?
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.
… these are the same tokens used for in-store payments.
… so we are leveraging what already existed in a better UX
Gerhard: Have you checked your transaction dialog with EMVCo expectations? Could we use this flow for SPC?
… with SPC we can achieve the same look and feel.
… Stephen, what do you see in connection between SPC and SPA?
smcgruer_[EST]: From a technical perspective, SPA uses payment request API. SPA and Chrome are quite separate in that sense (compared to the browser implementing SPC as a payment method). The interesting part to me as well is that we can learn from each other.
… 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.
Gerhard: In both SPC and SPA there could be redirects (whether to Google or, e.g., for SPC a network). How do you see this intersecting with digital identity / wallets
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
Gehard: Can this be used outside of Europe?
Heman: Technically it's not regionally restricted
gkok: In V2 is the requirement that the merchant be a native app?
Hemen: V2 supports not only chrome but Android apps (web views)
gkok: Can you have an experience where you don't redirect to google domain ?
Hemen: Going forward we expect a V2 experience (with the payment sheet). This should work with chrome and native apps
gkok: What is the main hurdle to expanding this?
Hemen: We don't see major hurdles. There is some integration cost (to achieve trust model)
… we do see a lot of demand
Payment Links
Junhui He slides on Payment Links
Support for Facilitated Payment link type in HTML
Junhui: We have some updates from our previous presentation of this topic.
… reminder that this is to facilitate push payments
… today the most popular push payment UX today is QR code (from desktop to get to payment service from app or site)
… or on mobile-only to go from app to app
[Examples]
… in PIX, payment code is generated by the merchant (EMVCo merchant-presented QR)
… the user journey involves pasting a pix code in an app
… it's a lengthy UX
… In Maya payments (Philippines) example
… still need mobile device to scan QR code
… so the question is whether the browser can assist the user to improve the experience.
… some questions: can android intents help? Issues: (a) android only and (b) requires active integration by merchant
… payment request API could be used (but also requires active merchant integration and also a user activation is required
… there are also UX implications in checkout page in PR API case
… so we are exploring a more lightweight method
[Payment link proposal]
Junhui: merchant can easily put a <link> element in their checkout page
… we propose a new "rel" value of "facilitated-payment"
… (we did not use rel=payment since that's already in use for other things)
… advantage to our approach is that it's declarative (easy to add)
… not as intrusive for existing checkout flows
[Junhui shows some example <link> elements]
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
[We look at the corresponding flow diagram and then some mockups]
Junhui: In the example, instead of scanning a QR code, the user can just authenticate in the payment client
[Status]
Junhui: We are currently prototyping in Chrome.
[Security considerations]
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)
… regarding safe browsing, we can use safe browsing tools to reduce abuse risk.
… we are considering allow lists and signatures
Ian: One aspect of this proposal is how to identify different payment methods so that the browser can determine which apps are relevant for handling it. The current proposal is to use url schemes, which seems like a costly approach. In the discussion about the issue about custom URL schemes I propose using the media type attribute for identifying payment methods, especially since handling media types sounds like wallets handling payment methods.
Jean-Luc: How do you mean account-based payments?
… does the bank authenticate the user?
Jean-Luc: How does this differ from payment handlers?
Junhui: This is easier to implement than PH API. Regarding the account-based payments I'll defer to stephen. We need to think more about scalability.
smcgruer_[EST]: I view this approach as a different way to get at a conceptual payment handlers.
… it doesn't mean we'll support payment handlers the same way we do today on day one.
… this to me feels like a lighter way for the site to interact with a payment handler. This is declarative (not interactive)
… so in terms of Jean-Luc's question about "what is being handled"...conceptually that remains up to the payment handler. 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
Gerhard: We are working on defining a web link standard for defining QRs in another SDO
… I will reach out to you
… how is the browser parsing data to be able to display some info
smcgruer_[EST]: the goal of the payment link is to avoid having to parse QR codes
Gerhard: A user may have an intention to use an app. How does the popup get triggered?
Junhui: It's automatically displayed when we are parsing the DOM and find a payment link
Gerhard: Is that modal a payment handler or google pay in a specialized window?
Junhui: It's a chrome component to choose a payment method
… the final modal is controlled by Google pay
… the user has to link a payment account to google pay
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.
… if this being applicable to UPI, it seems like an interesting approach. I'd like to explore this more
Junhui: I think that a PIX account can be linked to Google Pay. But we have a separate solution for PIX solutions.
… for UPI I have not explored a lot yet.
Next Meeting
13 February