Re: [w3c/payment-handler] Return origin of payment app in PaymentHandlerResponse data? (#217)

Let's be clear on what is being asked: 

>  Merchants would like this type of “origin” information to enable the ability to manage their risk (ie. Payment types that have a significantly higher fraud chargeback rate), identify and address poor performance that don’t meet SLA’s

Unless a merchant is banning an origin outright, knowing the origin doesn't buy one much (particularly if it's a mix of fraudulent and legit payment responses). The merchant still needs to validate the `details` of each response in case they are legitimate. 

As I stated earlier, there are caveats here:
 
 1. The browser's payment sheet won't have an origin.
 1. Browser extensions serving as payment handlers won't have an origin.
 1. Native applications serving as basic card, etc. won't have an origin. 

Now, the case can be made that knowing that `evil.com` keeps sending fraudulent credit cards or tokens - but the tradeoff is exposing what site is serving as the user's wallet (i.e., privacy). 

I'm not entirely convinced yet that this would be an issue on any significant scale, but would be interested in playing out this scenario. 

The preconditions would be:

 1. A lot of users have somehow ended up at `evil.com` and allowed `evil.com` to serve as basic card. Or, `bank.com`'s service worker has been hacked, making it respond with bad tokens or credit cards.
 1. The affected people then end up at `merchant.com` and still opt to pay with `evil.com` (or think that) 
 1. ??? 

> and enable partnership opportunities for promotions, offers, or discounting based on payment type or “origin”.  
>

This is addressed by URL-based PMI + `modifiers` + `methodName`. Would you agree? 

It's literally what we show in [this example](https://www.w3.org/TR/payment-request/#conditional-modifications-to-payment-request)

You can't add "promotions, offers, or discounting" _after_ you get the payment response, only before. So getting the origin _after_ doesn't help with any of the above.  

> These are just a few use cases for which an “origin” could support – all of which are to enhance the customer experience (with the exception of bad issuer behaviors or customer behaviors around fraud … which should be addressed with a balance of customer experience and risk management). 

So, that only really leaves "we don't know who is spamming us with fake card data and tokens, but we'd like that to stop!" as the only reasonable ask... but again, that needs to be balanced with user's privacy wrt what wallet (origin) they are using. 


-- 
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/payment-handler/issues/217#issuecomment-334021866