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

> 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 (...)

The Payment Apps spec seems to specify the passing of the payment request to the payment app by converting the request to JSON, and POST'ing it to the url of the web based payment app ([here](https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#submitting-the-paymentrequest-to-the-payment-app)). This approach would make it difficult to pass a promise to the app. A `getPendingRequest` call would work better for that. The advantage of the POST, on the other hand, is that it's a very intuitive way to pass something to a web page.

> 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)

Yes, this would actually work perfectly well. As long as the user agent gets any response, it can close down the web context for the payment app and pass the response back to the merchant. It doesn't actually need to see any status information.

If I implement it this way, I don't strictly need any changes to the spec, but it would be nice if the cancel/error scenario was mentioned in the spec anyway, for clarity.

---
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-214902687