Should we standardise a callback mechanism for payment apps to communicate to 3rd parties?

[adrianhopebailie]

Migrated from w3c/webpayments#76

In w3c/webpayments#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).

Some of this (specific to the API shape) is now being discussed in #51)

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.

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

The discussion on the original thread indicated that some people felt this was important and others were not convinced there were use cases to justify it. A number of discussions suggest it is worth revisiting:

• complete() should take a string argument not boolean #17
• How are payment requests and responses passed between the browser and third-party native wallets? #50
• How are web-based payment apps supported? #39

[burdges]

There are pragmatic differences for browser extensions between interactions during payment and interactions after payment. A FireFox XUL extension could do this, but I think WebExtensions cannot do this. It needs to forwards the user to a fulfillment-like page controlled by the merchant with which it can interact.

Is that fulfillment-like page necessarily a real fulfillment page? I donno, maybe not. I like that the payee has committed to a financial transaction by that point, so as to prevent this from being used for all manor of same origin violations. There is nothing one can do about people who install extensions or payment apps willy nilly though, so maybe it does not matter for those cases.

It might matter more for pure web based payment apps though, as methods we introduce there cannot violate same origin anyways.

[adrianhopebailie]

It needs to forwards the user to a fulfillment-like page controlled by the merchant with which it can interact.

I disagree with this. The whole point of this API is to establish a payment conversation between the merchant (payee) and the user (payer) or their respective delegated payment service providers. The user experience must be controlled by the payment service provider of the user but driven by data from the merchant.

[burdges]

There is plenty you can do in the existing model, so I'm not exactly sure if a richer dialog is necessary. I have not paid a close enough attention to the use cases probably.

In any case, browser vendors have already abandoned older more permissive extensions frameworks like XUL to standardize on WebExtensions, which specifically disallows this for extensions. It's more complex anytime you poke holes in someone security model.

[adrianhopebailie]

There is plenty you can do in the existing model, so I'm not exactly sure if a richer dialog is necessary.

The primary limitation of the existing model is that the UI is entirely driven by the payee and actors on the payer side are only humans entering data.

This places a huge limitation on the types of interactions that are possible. For example, we would like to allow credit-push payments and more secure credential exchange which are not possible today.

In any case, browser vendors have already abandoned older more permissive extensions frameworks like XUL to standardize on WebExtensions, which specifically disallows this for extensions. It's more complex anytime you poke holes in someone security model.

Whether payments apps will be browser extensions or web apps or entirely stand-alone native apps (or all of the above) is as yet unknown. To some extent it will be determined by the user agents but this group should at a minimum define a web interface to payment apps.

[burdges]

A web app is necessarily much more restricted than a browser extension though.

An approach that afaik does not violate existing security models is : Interact with merchant/payee to choose what to purchase, do secure interactions with payment app to approve purchase, and finally do post-purchase interactions with merchant and payment app together. In principle, we could change the top context twice to do secure interactions with the payment app twice, but probably nobody wants that.

In particular, if the payment app has a rich interaction with the merchant from its secure context, then one should expect that payment apps occasionally get hacked by merchants who themselves got hacked. That's a risk anyways, but the hacker cannot ask "what is your balance or credit limit" without the rich interaction.

Also, these secure context only impact the flow from the user's perspective. A browser extension based payment app can certainly use rich interactions to actually do the payment once the user approves it.

[adrianhopebailie]

A web app is necessarily much more restricted than a browser extension though.

Correct, that is why it has been proposed that payment apps may also take the form of extensions or native apps.

and finally do post-purchase interactions with merchant and payment app together

What's the purpose of this final step? The current flow suggest that the user and merchant interact via the merchant's website until such time as the merchant is ready to initiate a payment request. They do that via the browser API which triggers the browser to perform it's function as mediator.

The browser is aware of the payment apps the user has registered (web or native) and what payment methods these support. The browser looks at the payment methods that the merchant supports and based on this finds a common set which allows it to prompt the user to select a payment app from a list of apps that all support at least one payment method that the merchant supports.

The user picks a payment app and the payment request is forwarded to the app. When the app has done it's processing (whatever that may be, depends on the payment method) it returns a payment response to the browser which in turn returns this to the merchant website in the form of a resolved promise that was returned when the original API call was made.

This proposal suggests that there is a need for the merchant and payment app to interact prior to the return of the response and that we should standardize a way for this to happen via a callback URL which the payment app uses to establish a back-channel session with the merchant.

In particular, if the payment app has a rich interaction with the merchant from its secure context, then one should expect that payment apps occasionally get hacked by merchants who themselves got hacked. That's a risk anyways, but the hacker cannot ask "what is your balance or credit limit" without the rich interaction.

This interface (directly between the merchant and payment app) will be via HTTP calls so I'm not sure there is a risk of the payment app getting hacked if the merchant is hacked?

[burdges]

What's the purpose of this final step?

You cannot communicate so much when switching from the payment app context back to the merchant context, plus it might not be reliable. It's safer to transfer tokens or whatever with separate API calls that do not exist before the user commits to a payment with that particular fulfillment page.

These APIs are themselves a hacking vector, but they are not necessarily an issue for this spec. And the payment app can more easily sandbox itself somewhat.

This proposal suggests that there is a need for the merchant and payment app to interact prior to the return of the response and that we should standardize a way for this to happen via a callback URL which the payment app uses to establish a back-channel session with the merchant.

Right, but what data does one actually need this step for? Is the merchant no longer meant to obtain the shipping address earlier in the process or something?

This interface .. will be via HTTP calls so I'm not sure there is a risk of the payment app getting hacked if the merchant is hacked?

I think this assumes lots about the payment app.

Just talking out my ass : If you've plugged this into a buggy BTC wallet with a bad PRF, then maybe an attacker could make you keep restarting a transaction until the PRF reuses a signature nonce, allowing them to drain your account on the blockchain. No actual "hacking" there per se. Just a bad PRF that's exposed enough to let the attacker determine when its state has wrapped. It's happened before that nonces were reused purely by accident. Those coins don't stick around long.

[adrianhopebailie]

Will likely be implemented in payment methods that need it. If it becomes a more generic requirement we can revisit.