- From: Adam Solove <notifications@github.com>
- Date: Thu, 01 Feb 2018 05:46:50 +0000 (UTC)
- To: w3c/3ds <3ds@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/3ds/issues/2@github.com>
I'm posting some flow diagrams and rough thoughts here so that they can be seen publicly during tomorrow's call. These diagrams leave out a lot of detail and are incorrect in some details. But I'm trying to make a few points about how, even at a very coarse level of detail, there are some conflicts between them that we need to work out before starting to think of a strategy for moving forward. Also note that these thoughts so far seem pretty negative, since they mostly point out challenges rather than solutions. But I'm actually super excited to try to find solutions: I just want to point out the challenges so we can start tackling them right away. ## 3DS2 101  ## PRAPI 101  ## Some fundamental issues  - We can't obviously push complexity to payment handlers because merchants cannot simply work with any handler that registers for that generic 3DS method. Nor can they hand over all the data involved to an unknown middleman that speaks to the 3DS server for them. - But we also can't push it onto the browsers, because they probably won't want to own things like complying with the tiny details of annually-changing payments industry specifications that they have no involvement with. ## How to resolve these issues? So what can the WPWG do to make 3DS compliance easier on merchants while requiring only a reasonable level of browser involvement? I see a couple directions but also problems with each of them: - Specify a payment method that allows the merchant to pick a specific 3DS server. The 3DS server could then implement a payment handler that is installed on-demand, but it wouldn't have access to the merchant page to actually fulfill the web flow... - Adopt the native flow so that the challenge can be handled by a payment app. But then every 3DS server needs its own native app which needs to be pre-installed for it to be useful to a customer trying to buy from a merchant... - Specify a 3DS payment method where handlers are the issuing banks, who are likely to already have an app installed on many of their customers' devices. But then how do all the flows that normally go through the 3DS server and card network happen between the merchant and issuer via PRAPI ...? -- 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
Received on Thursday, 1 February 2018 05:47:28 UTC