[webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76)

In https://github.com/w3c/webpayments/issues/55 there is a discussion regarding the appropriate mechanism for a payment app to communicate with the website (other than receiving a request from the website and then returning a response).

An alternative mechanism for this (that does not require explicit support in the API) would be for the payment request to include a callback URL and for the payment app to send any notifications of important user interaction or requests for updated payment details to the payee system via that URL.

![flow diagram](http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments/gh-pages/images/callback_flow.puml)

It's quite likely that payment apps will want the flexibility to communicate with the payee (or their PSP) after receiving the payment request but prior to responding back to the browser with a payment response.

On that basis it seems like a good idea to define a standard for providing this callback mechanism, either per payment method or universally.

**_Note:_** Such a mechanism is described in the [Web Payments CG proposal](http://wicg.github.io/web-payments-browser-api/#a-basic-purchase-flow) (see step 6) but assumes this mechanism would only be used to contact a *payer* payment services provider. Such a callback doesn't need to be standardized as it will be defined per payment method.

Standardizing this could be as simple as defining an attribute(s) in the payment request where the URL for this callback should be provided (if supported) or as comprehensive as describing how this callback mechanism should be used (referencing the HTTP API possibly).

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