@marcoscaceres @zkoch I’ve been working through this scenario and it's fairly complicated and additionally also seems like a pretty narrow edge case… Here’s what I’ve been thinking through: 1. The feedback provided by the rejection of the promise returned from updateWith() does not seem to provide actionable feedback because what will a merchant do with the feedback? If it was an error that should be shared with the user, how would the merchant do so? And if it is from malformed merchant generated data (bug/exploit), how would the information benefit the merchant? 2. What does this additional promise offer that’s better than failing the transaction? 3. If a merchant has malformed data via a bug/exploit, shouldn’t we just veer on the safe side and fail the request anyways. 4. Just generally, this seems unlikely that a merchant will have malformed information, and a large code change doesn’t seem hugely beneficial 5. If we are unable to make this change in the short-term, then Microsoft Edge will throw an exception if .then() or .catch() is called synchronously after updateWith() We would prefer to keep the implementation as is and think that having invalid data reject the entire transaction is a good solution to the problem -- 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/pull/418#issuecomment-280812416
Received on Saturday, 18 February 2017 01:57:22 UTC