Re: [w3c/browser-payment-api] an event to providing standards for push payment methods (#223)

@ianbjacobs said:

> I suggest that functionality that is needed for payment apps be specified in the payment app specification

I disagree, the requirements here will impact what is passed in the request (and this PR is for a change to the PaymentRequest API). That said, the features required here are not required for all payment methods so we need to figure out if they SHOULD be put in the PaymentRequest API or belong only in the Payment Method-specific Data.

@rvm4 said:

> Historically we have punted on considerations for these kinds of apps/method

I don't think that is the case. My understanding of the groups position is that we are waiting for more information on what is required so we can decide if this should be put in the PaymentRequest directly or if it is sufficient to use payment method specific data.

This PR suggests that an event be fired when the payment app is selected by the user which would allow the website to trace the payment later but there are a few issues:

1. It returns an ID that is generated by the payment app and we have to date assume that there is no way for the payment app to communicate with the browser after invocation and before returning the final response.
1. It doesn't define how the website would use that id and the idea of "querying the payment app" for the status seems like an unlikely possibility given the current architecture.

There was a lot of interest in solving this at the F2F. Perhaps the best thing to do here is pull together a group of interested parties to first document the possible flows so we can analyze these for possible failure scenarios. Once we have this we can effectively design mitigations.

---
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/223#issuecomment-233638153