Payment app discovery

[andrewpaliga]

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 a supportedMethod. 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 or suggestedApps 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.

[rsolomakhin]

I would prefer the choice of alwaysShow to be left to the user agent. I suspect that Chrome will indeed suggest apps that merchant supports, but the user does not have. However, I would not want to dictate this behavior to the other browser vendors, which might have their ways of thinking about this problem.

[kirkalx]

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.

[rsolomakhin]

@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?

[ianbjacobs]

@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 https://github.com/w3c/webpayments/issues/112 (Should we support payee knowing user has payee-controlled payment app?)

And I would also relate this to https://github.com/w3c/browser-payment-api/issues/30 (Should we define nesting/grouping semantics for payment method identifier matching?)

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 equivalence testing (see my PMI notes [1]). But the payee could make different sorts of declarations around these payment identifiers, such as:

1) I support X 2) I do not support Y. (This is useful when X is a set and Y is a member of the set; see issue #30 ) 3) If the user doesn't currently have support for Z, encourage the user to get some support for Z, such as by installing the payment app with the following name at this URL. (Your suggestion above.)

  Note that "doesn't have support for Z" could include:
     a) User has an app that supports Z but user has not yet enabled Z
     b) User has no app that supports Z

 Mediator behavior would depend on a variety of conditions such as user preference
 for recommendations, etc.

I do not believe we are planning to support payee queries of what the user has installed, so sending "recommendations" seems like the right approach.

If the API does not support this feature (e.g., in v1), the payee can still recommend apps during checkout but before the user pushes on the "buy" button.

Andrew, can you say more about how useful you think the "suggeted app" featured would be to merchants?

Thanks!

Ian

[1] https://github.com/w3c/webpayments/wiki/PMI_Notes

[halindrome]

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.

[kirkalx]

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?'.

[halindrome]

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.

[kirkalx]

"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...'

[adrianhopebailie]

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.

[andrewpaliga]

Andrew, can you say more about how useful you think the "suggested app" featured would be to merchants?

• It can be beneficial for a payee to showcase the payment methods they support to increase conversation rates. Take financing options like Klarna and Affirm for example. They support "pay later" or "pay in instillments" functionality. These are payment options you'd always want to suggest or offer as options in your checkout as a merchant. It's easy to signup during checkout with the options.
• Same goes for digital wallets like such as Mollie or or MOLPay. They support a slew of payment types. Always suggesting Mollie as a payment app in checkout would ensure user's are aware that they have many options to pay with.
• Ditto for cash-on-delivery methods that are very popular in South America and India. ComproPago comes to mind.

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.

I would prefer the choice of alwaysShow to be left to the user agent.

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.

[andrewpaliga]

3) If the user doesn't currently have support for Z, encourage the user to get some support for Z, such as by installing the payment app with the following name at this URL.

I like this approach. Ideally the "suggested" or "available" payment apps would be listed in payment app selection screen for the user.

[nickjshearer]

It can be beneficial for a payee to showcase the payment methods they support to increase conversation rates

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.

[adrianhopebailie]

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

1. Add a section to the payment request where a payee can suggest payment apps that they know support payment methods they also support.
2. Allow the mediator to also have a "backup" list of payment apps they know about and can suggest to the payer.
3. Define an algorithm for the mediator (browser) that populates the app selection choices (in the following order of preference):
   1. The set of apps that are already registered and known to support the supported payment methods in the payment request.
   2. The set of apps suggested by the payee
   3. The set of apps suggested by the mediator

Considerations

• The size of the list presented to the payee. Will the suggested apps ever even be shown?
• The change of focus when a user decides in the midst of a payment to go off and register a new app.

(Both sound like nice areas for UAs to differentiate and offer users a great experience)

[ianbjacobs]

@adrianhopebailie, regarding your proposal:

• I don't have a good understanding of the use case where the mediator would want to inject app recommendations. Furthermore, if this is something that browsers want to do, they probably can do so without requiring us to standardize anything. So for the moment, I would support the "payee suggestion" part of the proposal but not yet the "mediator suggestion" part of the proposal. I'm open to hearing more rationale, of course.
  • Regarding the algorithm for populating the app selection choices, I would rather that we not specify order. Instead we might say something like "The mediator must clearly distinguish installed payment apps from suggested payment apps."

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

[adrianhopebailie]

I don't have a good understanding of the use case where the mediator would want to inject app recommendations.

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).

Furthermore, if this is something that browsers want to do, they probably can do so without requiring us to standardize anything.

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.

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.

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.

[andrewpaliga]

+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.

1. Allow the mediator to also have a "backup" list of payment apps they know about and can suggest to the payer.

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.

[ianbjacobs]

@adrianhopebailie,

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 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:

• The mediator must distinguish for user-installed payment apps, merchant suggestions, and user agent suggestions.
• The mediator should maintain the order of merchant suggestions when making them available to the user.

I expect user agents will distinguish themselves by offering additional features such as:

• Allowing the user to select a default payment app for a given domain, to make it easier to pay.
• Allowing the user to easily store credentials in the browser when there are no registered payment apps.

We should not specify that sort of behavior.

I think in general we SHOULD respect the order of things as provided by the payee.

+1

Ian

[adrianhopebailie]

@andrewpaliga asked:

What would be an example of an payment app on this list?

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:

The mediator must distinguish for user-installed payment apps, merchant suggestions, and user agent suggestions.

In this instance the user agent is the mediator so I'm not sure what this means.

Allowing the user to easily store credentials in the browser when there are no registered payment apps.

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)

[andrewpaliga]

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).

[halindrome]

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.

[adrianba]

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).