Re: [w3c/webpayments] Registration: App supports method but user has no instrument for that method (#110)

> when the payment app presents a user interface that allows for the selection from a list of one or more payment methods

This is a good example of what I don't think we should be saying at all :smile:

We don't care HOW payment apps work. All we require of payment apps is that they accept a payment request and return a response (and make it possible to query which methods they support).

If somebody defines a payment method and an app claims to support that method then it's the person/company/scheme that defines the method that will care about the HOW.

If that app happens to support many methods then the way they help users choose which one to use is a payment app thing.

One caveat is that we may define an algorithm for ordering or preference that we recommend they follow but I'm not sure how we would ever plan to "enforce" that given that we are hoping for there to be 100's of different payment apps out there.

At the end of the day we need to remember that payment apps are chosen by the user. So if they suck the user will choose another one. Hopefully our architecture creates a level-playing field so that market forces really do force payment apps to be either awesome or obsolete.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/110#issuecomment-210132203