search

w3c / payment-handler

Payment Handler API
https://w3c.github.io/payment-handler/
Other
73 stars 42 forks source link

Payment App Decline #92

Closed rvm4 closed 7 years ago

rvm4 commented 7 years ago

This has probably already been discussed somewhere, so apologies ahead of time. If a payment app is able to match the payment method a merchant asked for but choses not to for whatever reason (technical limitations, fraud concerns, rollout gating, etc) is there affordance for the payment app to silently decline to be part of the payment app selection process for a particular payment request? Essentially, does the payment app have a means of not being a listed option for a given payment request?

rvm4 commented 7 years ago

As a solid example, let's say shadycompanywithhighprobabilityoffraud.com makes a payment request. Even though I could service that request, I probably don't want to and at the same time don't want to allow the user to select my payment app only to instantly get an error.

ianbjacobs commented 7 years ago

Hi @rvm4,

It seems to me that the canHandle() function could fulfill this role [1]:

"The canHandle member indicates a function that is responsible for determining whether the payment app being registered is capable of handling a given request."

Please review that text and let me know if you think it meets your needs.

Ian

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manifest

rvm4 commented 7 years ago

It looked promising, but goes out of its way to state that the api would not have network access. That makes any sophisticated gating not possible.

ianbjacobs commented 7 years ago

This is tricky. The payment app itself could connect to the network.

I had a conversation yesterday about this topic; functions are going to be tricky according to our colleague Marcos. I am sure we will discuss this further. So it's good to have your use cases enumerated.

Ian

marcoscaceres commented 7 years ago

I was just about to say... ;)

rvm4 commented 7 years ago

I'll go ahead and lump this into the same topic. What information will the mediator provide to the app towards this end? A referring URL would be a minimum, but other user data could be useful as well, but I'm not seeing such data passed to the payment app.

ianbjacobs commented 7 years ago

@rvm4,

The mediator passes to the payment app:

Note:

Ian

Ian

tommythorsen commented 7 years ago

@rvm4

It looked promising, but goes out of its way to state that the api would not have network access. That makes any sophisticated gating not possible.

I think that a mechanism for letting the payment app silently opt out of the payment request list by contacting a backend sounds unfeasible for two reasons:

  1. Privacy: Letting the backend register every payment request attempt made by the user for a given payment method does not sound great, and can easily be abused by a data-greedy payment provider.
  2. Performance: If this mechanism is going to work, it means that the payment mediator cannot show the list of payment options until every single payment app has been given the chance to talk to its backend and see if they want to do the payment request or not. This will probably cause an unacceptably large delay for the user, and can turn into a huge obstacle for the adoption of Web Payments.

I would suggest using canHandle() for opting out where this can be done without making a network request, and for other cases, the payment app can reject the promise it passed to respondWith() as described in 10.5 Payment App Response. This will of course be visible to the user, but I think that in any case, if the merchant is so shady that the payment provider does not want anything to do with it, this is useful for the user to be made aware of.

@ianbjacobs

Should we be passing the payment method identifier for the selected payment method?

The current implementation in Chrome does not have the user select a specific payment method. Instead, the user picks a payment option, which can map to multiple payment methods. It is up to the payment app to figure out which payment method to use, in the case where there are multiple applicable payment methods.

rvm4 commented 7 years ago

I understand that it is challenging, but the user experience seems really poor here. Let's take a use case as simple as "we will only support payment requests if the user and merhant are in the same geographical region". I don't know why that would be a use case, but it is demonstrably realistic. In this case the payment app will appear to users to be very unreliable since it will throw an error whenever they attempt a purchase on an international site.

ianbjacobs commented 7 years ago

Some additional notes:

I'll put this topic on the agenda this week or next.

Ian

rvm4 commented 7 years ago

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.

dlongley commented 7 years ago

@tommythorsen,

This will of course be visible to the user, but I think that in any case, if the merchant is so shady that the payment provider does not want anything to do with it, this is useful for the user to be made aware of.

+1. In fact, I think it would be downright mystifying if a Payment App that I usually pay for things with all the sudden doesn't show up for a website that, AFAICT, accepts the same kind of payment I'm used to using. I'd think there was a problem with the Payment App or my browser. I'd be totally unaware that the merchant had been blacklisted by my Payment App.

dlongley commented 7 years ago

@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.

rvm4 commented 7 years ago

That is an interesting and reasonable way to view the experience. I suppose it could be acceptable to have the payment app decline with appropriate messaging, but only if it is hassle-free to make another app selection.

On Thu, Jan 19, 2017 at 3:39 PM -0800, "Dave Longley" notifications@github.com<mailto:notifications@github.com> wrote:

@tommythorsenhttps://github.com/tommythorsen,

This will of course be visible to the user, but I think that in any case, if the merchant is so shady that the payment provider does not want anything to do with it, this is useful for the user to be made aware of.

+1. In fact, I think it would be downright mystifying if a Payment App that I usually pay for things with all the sudden doesn't show up on a website that, AFAICT, accepts the same kind of payment I'm used to using. I'd think there was a problem with the Payment App or my browser. I'd be totally unaware that the merchant had been blacklisted by my Payment App.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/webpayments-payment-apps-api/issues/92#issuecomment-273933542, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ARKSKT8eQq9-ThAPKfBhCzhVfCcfPTSAks5rT_QLgaJpZM4LnikN.

rvm4 commented 7 years ago

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:

@rvm4https://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 GitHubhttps://github.com/w3c/webpayments-payment-apps-api/issues/92#issuecomment-273934316, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ARKSKbgHvg0kRe46IsXnakwNehQYzHODks5rT_UJgaJpZM4LnikN.

dlongley commented 7 years ago

@rvm4,

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.

Yes, but I may still be surprised that my Payment App of (usual) choice doesn't show up -- and I'd be wondering why. I'd rather know why ... and have it be easy to make another selection (as you mentioned above).

Edit: To add, I do think this is a different scenario from when my preferred app simply doesn't support the payment methods offered on the site. I'm imagining a case where I am clearly led to believe it does, but for this one site it's simply not showing up.

rsolomakhin commented 7 years ago

Once invoked, the payment app can choose to fail, and the merchant will get back a fail message for the PR API invocation, without information about why. So this sort of "decline" is possible, it's just after the matching phase.

If one payment app fails, Chrome lets user select a different payment app. Chrome does not notify the merchant website about any app failures.

I suppose it could be acceptable to have the payment app decline with appropriate messaging, but only if it is hassle-free to make another app selection.

That's how Chrome works today.

ianbjacobs commented 7 years ago

Given the input so far, I am leaning toward this perspective:

I think this is preferable to silently failing to match. I agree with @tommythorsen that "it would be downright mystifying if a Payment App that I usually pay for things with all the sudden doesn't show up on a website."

Ian

rvm4 commented 7 years ago

There are other cases to consider here though. In the case of recommended apps, if the merchant recommends my app, but I already know that I am unable to service any requests for this merchant/user pair at this time, then what?

dlongley commented 7 years ago

@rvm4,

There are other cases to consider here though. In the case of recommended apps, if the merchant recommends my app, but I already know that I am unable to service any requests for this merchant/user pair at this time, then what?

Seems like an unfortunate corner case, but in the event it occurs, I would think you'd want the user to install your app and then provide them with a message letting them know that you just temporarily can't service the merchant/user -- and perhaps let them know when you may be able to again. It would be nice to have the communication channel with them and to set the opportunity for them to come back and use your app later.

ianbjacobs commented 7 years ago

@rvm4,

I realize through your question that up to now the assumption has been "anybody can recommend any app." The ways that the payment method owners and payment app providers can control their usage include (1) the payment method manifest (cf digital signatures etc.) and (2) running and notifying the user that the payment app cannot be used for payment (as we've discussed on this thread).

Your point raises another possibility: that only some parties can recommend some payment apps. This could be done with some data provided by the app owner, along the lines of:

(One could also imagine positive expressions of these values: include lists.)

I would have concerns about the user silently losing the ability to use a payment app at a particular origin. However, if the user were able to control these lists, that might be interesting. Thus:

Comments very welcome!

Ian

ianbjacobs commented 7 years ago

At the 24 Jan meeting we resolved to close this issue with the recommendation that payment apps that wish to decline to make payments for a given merchant (or any reason) do so transparently with notice to the user.

https://www.w3.org/2017/01/24-apps-minutes.html#item03

Note: We could augment the protections for payment app providers by enabling them at registration to provide whitelists or blacklists about merchant recommendations. We have not resolved yet to do so.