Re: [w3c/3ds] Some high-level issues to discuss (#2)

@asolove-stripe I don't share your opinion on the likelihood of issuers providing the payment handler.

In my experience that is exactly what they want to do, either directly or via some co-branded application like MasterPass. The experience of logging into my bank's online banking website and having a SW installed that henceforth is able to handle 3DS transactions for me seamlessly is very appealing. I also think issuers have the advantage that a user is far more likely to install a handler from their bank to handle card transactions using the card issued from that same bank that anything else.

Market predictions aside, as I see it the goal should be that instead of the merchant needing to do the "fingerprinting" on behalf of the issuer, the payment handler does it. This makes much more sense because they are trusted by the user. For me this is one of the main goals of this whole project, make things simpler for the merchant and give control back to the user.

A handler that is running in a SW context in the browser (leveraging the Payment Handler API) has pretty much the same capabilities as a script being run in the merchant's Window context. In fact, it has the advantage of being able to access APIs that may require user permissions (like geolocation) and getting that permission once and then being able to re-use it multiple times in future.

In the app context (e.g. an Android app) the handler can run the SDK you have talked about.

My expectation is that for a payment handler to advertise that it supports the 3DS2.0 payment method 
it must be capable of returning this contextual data to the merchant in the PaymentResponse. 

The merchant and acquirer have no need to understand this data (or do they, maybe part of it?) so I would expect it can be encrypted in such a way that it can only be decrypted by the issuer?

What this would establish is an ecosystem where anyone can publish payment handlers capable of supporting 3DS2.0 but ultimately the gatekeepers are the issuers (which I believe is the desire of EMVCo?).

If an issuer receives data from a handler it doesn't recognize or trust then it will decline the transaction or request a step up auth.

EMVCo could go a step further and maintain a whitelist of handlers and host a payment-method manifest for 3DS2.0 too

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/3ds/issues/2#issuecomment-365886159