Re: [w3c/webpayments] How can a Web Based Payment App cancel the payment flow? (#128)

So, looking at this more closely ...

When a payment request occurs, I would expect the user agent to instantiate the Web-based payment app of the user's choice, and then that payment app would make a call to get an interface to the payment request data. To my knowledge, this hasn't yet been specified, but we called this `navigator.payments.getPendingRequest` in the WPCG spec proposal. We could also potentially use an event/message channel API for communication with the payment app, but messages could be sent prior to setting up a listener in the payment app and therefore missed (unless there's a clever way around that).

In any case, the payment app would be given an interface that has access to the payment request data and a Promise that should be resolved by the app to the payment response data. I think what we'd want to do in the case of cancellation, where the payment method wasn't actually used at all, is reject that Promise with an error, rather than resolving to payment response data with payment-method specific information in it. So this is a slight modification of what I said earlier.

This rejection would pass through the user agent and cause the merchant site code to receive an error and fall into the `"Uh oh, something bad happened"` catch in Example 1 in the spec. We may want to come up with a more specific error that indicates cancellation and that may allow user agents to recover and offer another option -- but I don't know how others feel about that level of complexity.

If we don't do it this way, then we would end up encoding the error in the payment response data itself (`details` in the `PaymentResponse` in the spec) -- and it would be up to payment methods to specify this information. They could, for example, encode this as a "refusal to consent". However, I can see how this kind of cancellation could fall outside of the domain of any particular payment method -- in which case the rejection of the Promise with an error that indicates cancellation seems like a valid approach.

Again, others will want to weigh in on this design.

---
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/webpayments/issues/128#issuecomment-214892762