- From: Adrian Hope-Bailie <notifications@github.com>
- Date: Mon, 01 Aug 2016 08:33:57 -0700
- To: w3c/webpayments-payment-apps-api <webpayments-payment-apps-api@noreply.github.com>
- Message-ID: <w3c/webpayments-payment-apps-api/issues/14@github.com>
Migrated from https://github.com/w3c/webpayments/issues/169 by @ianbjacobs Up to now we have described the following user experience for third party apps 1. User pushes a "buy button" on the merchant site. This causes the browser to display matching apps (or their instruments) 2. The user selects an app and the browser hands control to the app. 3. The user then selects a way to pay from within the app. It has been pointed out that when there is only one match, it would be a bad user experience to have to select the same information twice. Therefore, it has been suggested that, in essence, we combine 2 and 3 above into a single selection when there is just one match. I don't yet know whether this should be a requirement; my guess is that it should not be, but that everyone will seek the improved user experience anyway. The question is: what information is required (if any) to enable this better user experience? What does the specification need to say? For example, if we support the ability of mediators to display specific payment instruments (e.g., by showing a card nicknamed "My favorite credit card") then ideally I should be able to click on that in the mediator to complete payment. One way this could work would be that when I click, the mediator hands off control to the third party payment app, which immediately returns data given the payment method in question (a credit card). So step 3 turns out to "still exist" but it happens without additional user interaction. Is this how others view third party payment app interactions working? --- 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-payment-apps-api/issues/14
Received on Monday, 1 August 2016 15:39:57 UTC