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

@adrianhopebailie,

I'm not convinced our abstraction is being done in the right place. I'm not totally opposed either, but it feels like the modeling isn't quite right. It is a departure from the existing ecosystem -- where issuers give people instruments which they can then use with a variety of different processors. Whether or not that's a good idea can be debated. I do think, without some changes, we're potentially missing an opportunity to make it easier for payment app developers to get access to payment instruments in a standard way.

If we define an API to register payment instruments and pass those to payment apps during payment, then payment apps are no longer required to implement N different ways to get a user's payment instruments into their app. If we loosely couple payment instruments and payment apps, then we make it possible for payment app creators to innovate independently from payment instrument issuers and we can have a simple standard (basic) format for providing the instrument information to an app. From a user perspective, it would be nice to only have to register instruments once -- and then be able to swap out which apps to use to pay with them. There's also a certain amount of "payment app lock in" that may occur if we don't decouple.

With loose coupling, users can acquire payment instruments from issuers and then independently change the payment app associated with that instrument as they discover new or more interesting payment apps that support the instrument's scheme. This does not disable entities that want a tighter coupling from operating, it just enables more pathways for innovation and user choice.

I do see another abstraction layer on top of payment instruments being useful, but not necessarily as a hiding of payment instruments as a detail of payment apps. Rather, I see that we could create "keys" to payment apps where these keys are what users select when making a payment rather than selecting a payment instrument or a payment app. A key always links to a payment app, but it may also contain payment instrument information that makes it possible to change its link to another compatible payment app.

So here "key" a doubles as a payment app selection device and something can be potentially used by that app to make a payment. For example, a key may be a Visa card or a bitcoin private key, or it may be a "Bob Pay Key" that will only work with the "Bob Pay" app. Some issuers will create keys such that they only work with their app (the issuer *is* the app creator). But other issuers will want to issue keys that can be used by a variety of different payment apps.

In either case, when a payment request arrives, the user will be presented a list of their keys that match the available schemes. A key may be a Visa credit card that they have associated with their currently favorite payment app for processing Visa cards or a key may be a "Bob Pay Key". The former can be edited to change the payment app link as the user discovers and registers more interesting payment apps. The latter cannot -- it will always load the Bob Pay app. However, once Bob Pay is invoked, it may have its own mechanism for managing traditional "payment instruments" for the user. It will be up to Bob Pay to implement proprietary mechanisms to get the user's payment instruments into their app.

With this approach, there is support for the existing ecosystem and room to innovate in both spaces while keeping the user selection UI simple. Some users will just get a Bob Pay key and always use that to pay. Other users will get instruments from issuers and use a variety of different payment apps -- and have the choice to swap them out.

To be clear, I think an abstraction is helpful here, but we need to be careful that we don't lose important features of the existing ecosystem or dampen user control and choice in how we go about modeling it.

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