Re: [w3c/browser-payment-api] Update promise rejection (#187)

Regardless of how we expect this to behave, it needs clear documentation.

I'm a little perplexed by what @adrianba is proposing here, though. Let's imagine that I'm running a website that can only ship to the US and Canada. I get a `PaymentRequestUpdateEvent` with a US address, and update my shipping methods and total appropriately. Then I get a PaymentRequestUpdateEvent with an address in Finland. In @adrianba's modely, my options appear to be:

1. Ignore the event, and leave the US pricing and shipping methods in front of the user
2. Call `updateWith()` and do something odd like removing all shipping options and zeroing out the cost of the shipping line
3. Call `updateWith()`, and reject the promise, which has exactly the same effect as (1).
4. Abort the payment request, which will close the interface the user is interacting with, leaving them befuddled and a little angry.

What I'm proposing is that the optimal user experience here would involve giving the website a means to say "Sorry, but that change doesn't work for me. Go back to how it was, because that was fine." In the model @adrianba is proposing, this simply isn't possible. I'm proposing that (3), above, could easily serve this purpose. It's not clear why having the browser keep track of the previous shipping address or previous shipping method for the duration of event processing would be in any way complicated.

---
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/browser-payment-api/issues/187#issuecomment-218767692