- From: Shane McCarron <shane@spec-ops.io>
- Date: Wed, 9 Mar 2016 11:09:00 -0600
- To: "w3c/webpayments" <reply+00f16b1ca9353eed1df3a123d2cf3c08989869ffb5d2727392cf0000000112f7e9e592a16>
Received on Wednesday, 9 March 2016 17:09:04 UTC
See also https://github.com/w3c/browser-payment-api/issues/6 <https://github.com/w3c/browser-payment-api/issues/6> where we have discussed this. On Wed, Mar 9, 2016 at 7:40 AM, mattsaxon <notifications@github.com <mailto:notifications@github.com>> wrote: @adrianba <https://github.com/adrianba>, @adrianhopebailie <https://github.com/adrianhopebailie> How does the architecture differentiate a payment app from what the mediator is responsible for in terms of data provision? e.g. The API allows for shipping address to be returned, but it is not clear where this comes from in the architecture, if it can come from a nominated payment application, this may not be a problem, but if it comes from the mediators, we have a lockin or data synchronisation issues across platforms and browsers. — Reply to this email directly or view it on GitHub <https://github.com/w3c/webpayments/issues/42#issuecomment-194300423>. -- Shane McCarron Projects Manager, Spec-Ops
Received on Wednesday, 9 March 2016 17:09:04 UTC