Re: [webpayments] How are third-party native wallets integrated? (#42)

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

I think how to deal with this depends on the extent to which someone defines a cross-platform payment app.

I have heard comments that suggest people want to support native apps (especially on mobile) that can be payment apps. These apps will interface to the browser in a platform-specific way. I have also heard some people propose a web-based payment app that runs in a special browsing context. While it is possible to have this browsing context be platform-specific, I think the desire of those proposing web-based apps is to have a cross-platform interface.

So, in the native app case, how the browser and the payment app choose to integrate or not around shipping address and other similar data is up to those defining the interface to native apps (presumably the owner of the platform or the browser vendor utilising existing native platform capabilities). For the cross-platform web-based payment app case then I think it is for the spec describing how those work to define this.

I don't think the API needs to take a view on where the data comes from.

With that said, it is possible that someone will find implementation barriers on platforms today that cause us to rethink some of the design. That's not limited to this question. For example, the spec currently calls out a "delegated" state but we haven't really decided yet what that actually means in practice for developers.

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