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

@mattsaxon 

I think these additional requirements would be encapsulated in different payment methods. (This is one of the main reasons I am advocating for the term "payment method" as opposed to "payment scheme")

One of the key benefits of this API is that new payment methods could be introduced without a user even being aware.

As an example, a bank may publish a payment app which allows their users to pay using their bank issued cards. As such the app may advertise that it supports a payment method called "Legacy Visa Credit" or similar.

As time goes by the industry may standardize on a better way to do card payments that includes tokenisation or similar. This new method would need to be supported by both the app and the PSP's of the merchants where the user uses the app as it's likely the message schema for the request and response messages will have changed.

If the app supports this new payment method it can add it to its list of supported payment methods and going forward when the user uses that app with a merchant PSP that supports the new payment method that's the method that will be used (invisible to the user).

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