Feedback on Roy's document on Push Payments

Regarding the document at:
https://github.com/w3c/browser-payment-api/blob/gh-pages/failure-handling.md

I think that the crux of solving this is the ability to keep the payee
informed of the state of a payment throughout the flow and, if they stop
getting state updates the ability to reference that payment when issuing
queries or reversal requests to other systems.

This kind of thing is well defined for protocols like ISO8583 (card
payments) but there are a few models. For example in ISO8583 you can use
either positive or negative completion. I.e. Assume a response has been
delivered unless you receive a request to reverse the original request vs
don't commit a tx until you get confirmation that the response has been
received.

I think our biggest risk is in the interactions between the
mediator/browser and the app. I think we can be fairly confident that once
the browser has the payment response it will be passed on to the payee
website.

One simple thing we can do to help developers of both payee websites and
apps is give every request a unique identifier. I'd be interested to hear
Adrian and Zach's thought's on this but my suggestion would be that
whenever a new PaymentRequest object is instantiated it internally
generates a new UUID which is accessible via a property of the object so
the website can record it before even calling show().

This same UUID (generated by the mediator) would be passed to the payment
app and payment methods would be expected to ensure that this identifier
travels with the payment through it's life-cycle so that the payee is able
to query the state from any component in the flow.

The next challenge is notifying the payee when the user has selected an
app/payment method so that if there is no further communication from the
mediator/browser the payee has some idea of how to query the status of the
payment.

Would an event that is emitted by the PaymentRequest object at that time be
sufficient?

The payee can assume that until they see that event the user has not even
picked an app and therefor there is no risk that the payment has been
initiated.

Note: It seems to me that unless we surface the actual instruments (and
therefor methods) using options as currently described in the payment apps
spec it is impossible to give the payee enough information to recover.

Finally, my recommendations for all push payment will be the following:

- Some form of signature on the request to verify the payee. ApplePay is
already doing this and it seems like a good idea if the payment is actually
processed by the app to ensure that some malicious code is not tampering
with the request before the app receives it.

- A callback URL in the request, or a static URL defined by the payment
method, that is used by the app to POST data back to the payee or payment
processing system rather than depending on the browser passing the data
back to the website which may or may not have timed out, lost focus, been
closed.

- A website that starts up and is able to determine that it was in the
middle of a transaction could then still pull the UUID of that transaction
from local storage and attempt to recover it's state.

Looking forward to the discussion!