- From: rvm4 <notifications@github.com>
- Date: Thu, 19 Jan 2017 15:45:48 -0800
- To: w3c/webpayments-payment-apps-api <webpayments-payment-apps-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webpayments-payment-apps-api/issues/92/273934802@github.com>
Well now you are over focusing on fraud. It doesn't have to be that extreme. It could be just a controlled rollout or technical limitation on offerings. On Thu, Jan 19, 2017 at 3:43 PM -0800, "Dave Longley" <notifications@github.com<mailto:notifications@github.com>> wrote: @rvm4<https://github.com/rvm4>, Yes, baking in code had occurred to me too, but doing so could leak specifics on internal policy. A common workflow would probably be to run some sort of risk model in the backend and decline payments that come from merchants that are demonstrably risky. Doing this in baked in code would require embedding the entire risk model data set, which is impractical and leaks information. One reason I'm using a particular Payment App may be because I trust it to help inform me when things like this happen. I would want it to let me know that the website I'm trying to buy things on is disreputable, not silently go away. In fact, if I were offered two equivalent Payment Apps, one that silently hid itself and one that explicitly warned me not to buy something on a particular website because it's shady, I would choose the latter. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/w3c/webpayments-payment-apps-api/issues/92#issuecomment-273934316>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ARKSKbgHvg0kRe46IsXnakwNehQYzHODks5rT_UJgaJpZM4LnikN>. -- 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/webpayments-payment-apps-api/issues/92#issuecomment-273934802
Received on Thursday, 19 January 2017 23:46:38 UTC