[webpayments] What gets registered - apps, wallets, or payment instruments? (#28)

>From [Payment Method Registration Specifications](http://wicg.github.io/paymentrequest/specs/architecture.html#payment-method-registration-specifications):
> One scenario is registering a new payment app. For example, this would allow bobspay.com to install an app into the user agent that would support transactions through the Payment Request API using the bobspay.com Payment Method Identifier.
> Another scenario is that of registering specific Payment Method Data within a payment app. For example, this would allow a user logged in to the Alice Bank web site to register their Visa credit card with the Visa payment app.

I don't know if the text above is stating that you can register both 'payment apps' and 'payment instruments' within payment apps. I think it is. If so, it feels like too many levels of indirection because the user will end up having:

1. A payment app selection dialogue.
2. A payment instrument selection dialogue within each payment app.
3. A payment instrument verification dialogue within each payment instrument.

This means 3 clicks at a minimum to make a payment in the general, non-optimized case. It also means more cognitive load on the person (hmm, do I want to use my Google payment App with my Visa card, or my PayPal payment App with the same Visa card?). Can you share payment instruments between payment apps? That is, this has the downside of requiring the user to have a multiple wallets and multiple cards in each wallet metaphor.

The Web Payments CG specs attempts to reduce the cognitive load on the user. You register payment instruments, full stop. The payment app is defined in the payment instrument. This means the general, non-optimized flow is:

1. Select a payment instrument.
2. Confirm payment.

There is ONE discovery process to get a collection of all of your payment instruments into the browser. You select a payment instrument and you're directed to the site or app that handles the UI for that payment instrument/app. The benefit with this approach is that you can share payment instruments between payment apps w/o placing the cognitive burden on the person. They only care about their payment instruments (card metaphor). 

Spec refs:
http://wicg.github.io/paymentrequest/specs/architecture.html#payment-method-registration-specifications
http://wicg.github.io/web-payments-browser-api/#payment-instrument-registration

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