Re: [webpayments] What is the appropriate conversational pattern for the API? (#55)

> Since the website has lost focus any callback to the website (whether via events, resolving promises or any other mechanism) freezes the UI in a "waiting" state until the website responds or the call times out.

The PaymentRequest API does require that you prevent a user from accepting a payment while the web site is given an opportunity to do something that might change the price (such as recalculating shipping costs) but that doesn't require a "frozen" UI.

> I don't believe that these calls can be made asynchronously as the use cases suggest user interface updates will be required once the browser receives a response.

I think it is essential that they will be made asynchronously. Making synchronous calls that result in I/O is a design anti-pattern that we need to avoid.

Your assertions are founded on a particular design for payment apps that we wouldn't implement in our platform so this wouldn't be a practical limitation. We haven't heard other implementers yet say they couldn't support this but that was the point I was making: we have to see what they say for their platforms rather than making general assertions about what might be the case.

Today the PaymentRequest API proposal has an event driven interface for getting to the final price before allowing delegation to another app. This supports your proposal that "...once we are ready to submit a payment request to the payment app we must have gathered all of the data required for the payment app to process the request as the payment app can't make requests back to the website for more data." But it doesn't require a move away from the conversation pattern that occurs prior to that point.

So I don't understand the need for an abstract issue about conversational pattern.

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