Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76)

> Can you clarify use cases around this and how common those use cases are?

 1. Payer adds a coupon to their payment and the payee has to recalculate the price
 1. The payment method supports DCC and they payment app needs to get a quote from the payee or their PSP for a price in an alternative currency
 1. Payer provides some detail that changes their tax calculation
 1. Payer indicates they are part of a loyalty program that qualifies them for a different deal (free delivery or lower price)

> It's the client that created the payment request, but now it's the server that is receiving certain change notifications

True, but it's quite unlikely that sending this via the client (using events or similar) would be very different. Consider that if the client needed to recalculate the payment request they would likely request it from the server anyway.

This is not a difficult flow to implement at all. When the client gets the payment response their first step would be to poll the server for any updates. The flow is still simple and  linear from the perspective of the client.

> Technically, this is possible given the current paymentRequest API if both the merchant and the chosen payment app wanted to take advantage of it. But again, I'm not so sure this is a case we need to support.

I agree. I logged it here to get input from the group because technically it's possible but we should decide if it's likely to be implemented widely enough to justify standardizing it.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/76#issuecomment-178200838