Re: [webpayments] Abstract payment architecture (#11)

@adrianhopebailie,

Having thought and discussed this a bit more, I think we can get the same decoupling even if we make the user selection "payment app"-based and let the payment apps handle the payment instrument registration details. We can perform the decoupling via a later standardization phase, by creating a basic standard payment instrument format and API that payment apps use in the future (we don't need to do this now). This keeps the payment mediator simpler and avoids any liability there (important for polyfills) but still makes broadening user choice and ease of use a possibility in the future.

Unfortunately, this means payment apps will have to deal with proprietary payment instrument registration and formats and so forth in the near term, but in the future, more standardization work can be done to reduce the amount of effort payment app developers need to put in to support new schemes and to help users avoid having to register payment instruments. Instead they could be issued and shared in a standard way.

In short, I now do think that pushing payment instrument details into payment apps may actually be the better way to go -- with an eye on potential future standardization of the basic payment instrument information and an API for registering/sharing tokenized instruments. Again, we needn't concern ourselves with that future at the moment, but it is important and good to know we're not taking a step that would make that effort more difficult.

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