Re: [w3c/webpayments] Payment Methods vs Payment Instruments (#124)

> As a UI developer, I would really like to be able to smash STEP 2 and STEP 3 together so that I could present Bob's two credit cards in the very first screen Bob sees, without him having to go through the extra step of selecting the payment app first. Is there a way the current specification allows for me to do this? Can this be done by having multiple "pay" actions with the same type?

The short answer is no. You can't have flexibility AND efficiency without some built in intelligence or sensible defaults.

There are a bunch of ways this could be done better:

 1. The browser allows the user to pick a default payment app and in this case the user isn't even prompted to pick an app. The browser might be smart enough to see, when a new app is installed, if it offers payment methods that are the same as others enabled by other apps and prompt the user at that time to set a default.

 1. The payment app allows the user to set rules for auto-selecting the right payment instrument to use. This is how we imagine payment apps differentiating themselves in the market through great UI.

 1. The user installs a different payment app for each payment instrument. If the user likes to pick instruments then this is the easiest way to get the same old experience but I suspect that this paradigm will change over time as this new API allows payments to be made with alternative (better) instruments than cards. 

 1. The vision of the interledger protocol is to solve for this matching problem dynamically by routing payments per transaction. So if the merchant and user both supported interledger as a payment method then there would be no need to select an instrument at all. See http://interledger.org for more details.

---
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/124#issuecomment-211988766