-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Payment app discovery #155
Comments
I would prefer the choice of |
If something like this is supported, it would seem logical to allow the user to easily express the wish to not be given that payment option again for that merchant or (at their option) for any merchant. |
@kirkalx I agree. The user agent should provide appropriate control to the user through settings. This is vendor specific and not exactly standardizable, though, right? |
@andrewpaliga andrewpaliga, Thanks for relating this to issue #110. We also had some discussion around this topic at our February FTF meeting: https://www.w3.org/2016/02/24-wpwg-minutes#item06 I think your point also relates to w3c/webpayments#112 And I would also relate this to #30 Here's why I make the (less direct) connection to the last issue. I still have as a design goal that the primary computation done on payment method identifiers is
I do not believe we are planning to support payee queries of what the user If the API does not support this feature (e.g., in v1), the payee can still Andrew, can you say more about how useful you think the "suggeted app" featured would Thanks! Ian [1] https://github.com/w3c/webpayments/wiki/PMI_Notes |
I can see the suggested app feature being an interesting way of a merchant continuing to support branding agreements (e.g., BigBox has an agreement with American Express that they will list American Express as an accepted payment method and feature it prominently). However, I can also see the brand (American Express in my example) not necessarily agreeing that a soft "ask" of the user agent is featuring their brand prominently. |
At worst, once the user has selected some other payment method, BigBox could redirect to a page saying 'Are you sure you don't want to use American Express?'. |
Sadly, our model doesn't work that way. Once it gets inside the paymentRequest API the user selects a payment app / payment method the payment completes and the Promise resolves with the payment complete. There is no method for the merchant to then say "wouldn't you rather use foo". The transaction has completed. |
"Sadly", yes. I might feel differently if I worked for BigBox or Amex though... EDIT: I guess they could always say 'Maybe next time you could use American Express because...' |
Please submit some concrete proposals for how this feature may be implemented. There appears to be consensus that it would be valuable however I think the priority and more detailed questions will be defined largely by how it proposed to be implemented and the impact that will have on the existing design. |
In general I think it's best to assume that no prior configuration will be done by the end user. Many countries have much lower cc penetration rates (<20%) than we see in North America. Most online payments are done via bank transfer or digitals wallets. Ensuring the buyer is aware of these payment options at all times would be of benefit to the merchant.
It would be difficult for the user-agent to manage payment app recommendations as these are very country specific. Almost every country in Europe has a different primary payment provider. Ie. ideal in Netherlands, Bancontact in Belgium etc. I think it should be up to the Payee to determine which payment apps are showcased. |
I like this approach. Ideally the "suggested" or "available" payment apps would be listed in payment app selection screen for the user. |
As long as we're considerate of the benefits to the payer as well. I can think of situations where a merchant might be inclined to push a payment app that's beneficial to them (perhaps they receive extra commission) and detrimental to the payer (the overall cost is higher). Any proposal should take into account the need to provide benefit to both parties, and to mitigate the potential for abuse. |
A question to address is; who should provide the suggested list? We seem to all be implying that it is the payee but if they don't should the mediator also be able to suggest some payment apps? Bare in mind that just as they track all sorts of other data on the Web browsers will very quickly have data on which apps support which payment methods (and maybe even how often payments are successfully processed by that app - see PR #153) and how to install those apps. They will be very well placed to give users options if the payee doesn't suggest anything. PROPOSAL
Considerations
(Both sound like nice areas for UAs to differentiate and offer users a great experience) |
@adrianhopebailie, regarding your proposal:
Issue #23 is about payment app ordering. I would suggest splitting your proposal into one part about the API supporting payee-suggested payment apps, and the second part is integrated into #23. Ian |
Sorry, I should have provided some more context. I had a conversation with @zkoch about this some time back in which he was concerned about the case when a user has no payment apps that can be used for the current payment request. This is what motivated him to suggest that the payment request have a set of payment app identifiers (as opposed to payment method identifiers) in his early registration explainer. I believe we've resolved that payment apps will not identify themselves using a payment method identifier but that doesn't solve the issue he raised (which @andrewpaliga has raised here).
That's okay but I'd want us to state that the suggestions from the merchant SHOULD take preference over any from the browser, unless there is a good reason to not state that.
I think in general we SHOULD respect the order of things as provided by the payee. This issue is specifically about a list of suggested apps (not payment methods) so I don't agree with splitting it. In any case, #23 is closed and I don't think this information justifies re-opening it. +1 - that the key here is differentiating between installed and suggested apps. Not sure we need anything in the spec to state this though, I'd imagine the browsers would deal with this as a UI consideration. |
+1 on modifying the payment request to allow the payee to suggest payment apps to the user. I also agree with @ianbjacobs on not being too prescriptive on the display of installed/available apps vs. suggested apps. They need to be clearly distinguished but I think it should be up to the mediator to implement the best user experience.
What would be an example of an payment app on this list? Would this list function solely as a backup? Assuming the user is already being shown 1) installed payment apps 2) suggested payment apps that the payee supports 3) what's left to show? My understanding is that the payee would need to already support any app that is recommended to the buyer. |
I understand the motivation for that suggestion. I am not sure I want to specify the presentation relationship between merchant-provided and browser-provided suggestions. Here's a counter-proposal for the case where we enable merchant and browser recommendations:
I expect user agents will distinguish themselves by offering additional features such as:
We should not specify that sort of behavior.
+1 Ian |
@andrewpaliga asked:
Imagine a website supports basic card payments but has not suggested any payment apps for the user to install so the payment request is likely to fail if the user has no payment apps that support basic card payments. In this instance the user agent might suggest one or more payment apps that support basic card payments, possibly even their own built-in payment app. @ianbjacobs said:
In this instance the user agent is the mediator so I'm not sure what this means.
This should be done by offering the user a built-in payment app suggested by the browser. If the process of registering a third-party payment app is necessarily harder than simply using the browser to pay then the system provides unfair advantage to the browsers and it's unlikely users will ever install third party apps (or even know they exist) |
I agree with this for North American CC-centric markets but depending on the market payment apps could be a necessity to pay with. Many bank transfer methods (popular in the EU) have regulatory requirements requiring a redirect to a website hosted by the bank. In these markets payment apps would be necessary to process payments (at least in the short term). |
I am not sure these things are orthogonal. That same 'unfair advantage' can be thought of as a barrier in that the default or easy behavior gets in the way of the normal process whereby you would discover a rich collection of options, including those that are offered by your bank and address the regulatory requirements in various regions. In other words, I think you are both raising important points. |
This issue is out of scope for the Payment Request API and there has been no activity since April. Considerations of Payment App discovery are being covered in the Payment Apps API spec and discussions on this topic should be directed there (probably the reason for lack of activity on this issue). |
The browser payment api spec suggests that the user-agent will display the intersection of payment apps that the merchant website supports and the user has installed. Many payment apps that Shopify supports do not require user registration as they either 1) provide an onboarding process as part of payment or 2) provide the option of processing credit cards directly.
PayPal is a good example of this. Once a merchant enables PayPal on their Shopify store, it is always presented as an option in checkout. If a buyer does not have a PayPal account, they are given the option to create one or pay via credit card. In the context of the
PaymentRequest
, a merchant would include PayPal as asupportedMethod
. The buyer may not have registered PayPal as a supported PaymentApp, however we do not want to exclude it from being a valid payment method to use.There are also payment apps that may be particularly useful for the specific goods the user is selling. For example bitcoin or net banking for virtual purchases. Or, financing methods for larger purchases.
Below is a screenshot of what the last step of our checkout looks like with multiple payment options installed by the merchant.
Should the ability for a merchant to categorize payments apps as
alwaysShow
orsuggestedApps
be defined in the spec?suggestedApps
would be those apps that the merchant would always want the user agent to provide as option to the user whether they have them installed / registered or not, this would also be a way for users to discover new payment apps.Note: There is some overlap between payment method discovery which has been discussed previously and payment app discovery but I think it's worth defining both issues seperately.
The text was updated successfully, but these errors were encountered: