search

w3c / payment-handler

Payment Handler API
https://w3c.github.io/payment-handler/
Other
74 stars 42 forks source link

Is the concept of payment app registration necessary? #8

Closed jnormore closed 8 years ago

jnormore commented 8 years ago

Have we ever considered removing the payment app registration concept from the spec and just letting payment apps handle the first-time experience in their own way? Most will handle it well, some have no first time experience.

It seems like the whole concept is just adding complexity to the customer experience, they have to make a decision to install one of many payment apps (some may be for the same payment method). This is an extra step on top of just selecting a way to pay, as they do today. As soon as you require the merchant to make a new choice around their purchase experience, you increase the possibility of cart abandonment.

From the merchant experience, we're reducing their ability to have confidence in the checkout experience their customers are getting. As a merchant, I want to know with certainty that if I'm supporting basic cards, for example, that the experience is first class (a specific payment app I trust, like the browser itself) or I'm going to bypass it and implement it myself, which changes nothing from how it's done today. As a merchant, I also now have to figure out a seamless way to get my customers to install these new apps, even if they already have an account or the apps have no need to registration (for example, paypal supports guest checkout).

From a payment provider perspective, the spec I have to implement has a lot more complexity. I have to now deal with this new registration flow, on top of any original registration I have to create an account/etc.

From a user agent perspective, it's definitely very useful to know what payment apps a user likes to use, but I would argue that this is still possible without the concept of registration. UAs can still remember what payment apps a customer used last, their preference on certain sites, etc.

msporny commented 8 years ago

As a merchant, I want to know with certainty that if I'm supporting basic cards, for example, that the experience is first class

I'm skeptical of this line of thinking. As a general rule, every merchant wants their customer experience to be first class. I assert that in addition to that, giving the customer the choice to pay in the way that they want to is preferable (from a customer experience standpoint) than via a limited set of "experiences" provided by the merchant.

To put it another way - the customer will choose to register and use the payment apps that /they/ find most compelling. I don't support an ecosystem where a merchant forces usability choices onto the customer because doing that will lead to an uneven playing field.

Have we ever considered removing the payment app registration concept from the spec and just letting payment apps handle the first-time experience in their own way?

Our company would like to provide software that helps our customers safeguard their cards, store verifiable claims, and help them manage their financial lives. In order for us to do this, we need a mechanism that enables customers to choose which payment applications they use.

It sounds like you're requesting that we remove this functionality? Or are you arguing for the removal of something more subtle?

jnormore commented 8 years ago

Manu, my underlying problem with payment app registration is that payment apps already exist today, they exist on the web, as native apps, etc and the majority have an existing registration process, but we're now saying that we want to add another layer of registration on top of that for each browser the customer is using.

I understand the wish to give customers choices and create an even playing field for new payment methods but in the end the merchant is going to have to support the underlying payment method that an app wants to support (your example would be storing basic credit cards, even then there's specific card brands). So unless one payment method becomes adopted by 100% of customers (no matter the app they use) there's still a requirement on the merchant to support the different methods, leading to the same uneven playing field you are trying to avoid. It's creating a somewhat even playing field for wallets that support storing the most popular (arguable) basic credit card, but the future of payments I see isn't to monopolize a single payment method, it's to make it easy for new methods to be adopted by merchants, a merchant will support the best ones for their subset of customers and enabling ease of competition will even the playing field.

msporny commented 8 years ago

we're now saying that we want to add another layer of registration on top of that for each browser the customer is using.

It sounds like we're miscommunicating. When you say "we want to add another layer of registration", are you talking about this call?

https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#paymentapp.register

Are you suggesting that we remove that call entirely?

Or are you suggesting that the UI shouldn't allow someone to register for a new payment app when they go to checkout?

Or are you suggesting something else?

jnormore commented 8 years ago

Are you suggesting that we remove that call entirely?

Yep this is what I'm suggesting

msporny commented 8 years ago

Yep this is what I'm suggesting

Ok, so you're suggesting we remove this:

https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#paymentapp.register

If we do that, how does a 3rd party payment app register with the browser so that the browser knows what payment apps should be shown to the customer when they go to buy something on a merchant site?

I would argue that this is still possible without the concept of registration

What's the mechanism you're proposing that replaces the concept of registration?

jnormore commented 8 years ago

What's the mechanism you're proposing that replaces the concept of registration?

I'm suggesting that registration is between the customer and the payment app, as it is today. The merchant specifies which payment apps (as well as methods) it supports -> UAs display the list (they can sort based on how that customer has interacted with those apps in the past if they want) -> customer selects one, if they don't have an account (if that's even a thing for that payment app) then they can be onboarded right there and then, as they do today (login pages contain a Register button as well).

I'm not formally proposing anything btw, I'm trying to figure out why it's necessary and stir up some discussion.

webpayments-specs commented 8 years ago

Good discussion Jason!

I don't think that merchants need to specify which payment apps they support in our architecture. There is the interesting case where payment app == payment method but... I think that will get sorted out as we complete the specification work.

The only thing this call does is provide a way for a payment app to inform the user agent that they are available. Native implementations may already have other ways to accomplish this (e.g., Payment apps on Android that integrate with the native payment mechanism and secure element). So this call is more for desktop or other environments. At least, that's where I think it will get used.

This does not add an extra step for an end user. Or at least no step they didn't need to perform already (teaching your phone about your credit cards). Unless I am really, really confused.

On Wed, Jul 20, 2016 at 12:02 PM, Jason Normore notifications@github.com wrote:

What's the mechanism you're proposing that replaces the concept of registration?

I'm suggesting that registration is between the customer and the payment app, as it is today. The merchant specifies which payment apps (as well as methods) it supports -> UAs display the list (they can sort based on how that customer has interacted with those apps in the past if they want) -> customer selects one, if they don't have an account (if that's even a thing for that payment app) then they can be onboarded right there and then, as they do today (login pages contain a Register button as well).

I'm not formally proposing anything btw, I'm trying to figure out why it's necessary and stir up some discussion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/webpayments-payment-apps-api/issues/8#issuecomment-234013176, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ8khoXrl7KwbXrzEKTo9lINdJhPBke5ks5qXlSfgaJpZM4JQ1XN .

Shane McCarron Projects Manager, Spec-Ops

ianbjacobs commented 8 years ago

@jnormore,

Thanks for starting this thread. It also picks up on some themes that our colleagues at Alibaba raised in London.

+1 to thinking about how to make registration minimally intrusive.

Note: In what follows, I use "registration" to mean "providing the browser with metadata about a payment app." There is no software installation. However, the metadata might include information about the user (e.g., credentials). (We can decide later whether it helps us solve any problems by limiting the term "registration" to the exchange of generic information only about the payment app and to use some other term to refer to "communicating to the browser some user-specific data held by the payment app.") Here are some scenarios (that you also touch upon):

The last bullet includes user consent, but here's a question: suppose I visit merchant.com's web site and they have an app. Should they be able to silently register their app as long as the payment app's origin is part of registration? On the one hand that would streamline app registration, but it might also create some spoofing opportunities. It would seem to me to be especially important to enable users to disable this automatic registration and delete this information and also not have it happen again for that site, etc. This sounds a bit complicated, but cookies might provide a model. I am instinctively reluctant to things that happen silently, but I support the goal of making registration painless.

There may also be some interesting curation opportunities, including by the browser. But imagine I can visit a site I trust that (like linkedin, twitter, etc.) lets me register a bunch of payment apps easily that I might want to try out.

Summary:

Ian

ianbjacobs commented 8 years ago

We discussed this at our payment apps call today: https://www.w3.org/2016/07/27-apps-minutes.html

Jason took an action to write up a proposal. Here is a partial summary:

There may be additional useful distinctions between what happens for open v. proprietary payment methods, but for now it seems to me that we captured the main issues by looking at merchant-recommended, browser-recommended, and user-self-initiated.

My sense is that we should still specify what data needs to be exchanged whenever the registration happens to take place via the browser.

Ian

halindrome commented 8 years ago

+1 to defining the messaging when registration happens via a browser. Native registration is clearly something we don't want to get into!

FWIW I don't know that there is really an interesting difference between "open" and "proprietary" payment methods from our perspective. I don't even think I know what that means. Payment methods need to have a defined way of message passing from the merchant <--> method right? Or are you envisioning some sort of out of band communication because a method has a relationship with the merchant?

ianbjacobs commented 8 years ago

@halindrome, regarding "open" v. "proprietary": It has been observed that for some payment systems, there is likely to be a 1-to-1 match between payment method and payment app, that is - it is likely only one app will support that payment method. We have taken, informally, to referring to those as "proprietary" payment methods. So far the distinction has been limited to discussions, but in the end, there may be no need to call out the distinction in the API(s).

halindrome commented 8 years ago

I can imagine a payment app that only supports a single payment method.... Paypal == Paypal. If we need a term for those, maybe we could call them "single method" or "single vendor" or "exclusive"?

ianbjacobs commented 8 years ago

So far we are calling them "proprietary." I don't want to spend a lot of time finding a new term, especially if it doesn't have any impact on the API.

adrianhopebailie commented 8 years ago

I believe this issue ignores the fact that most payment apps will not be registered as part of the checkout flow.

The PaymentApp.register() function will be called by payment app publishers and we have said we want to enforce origin based security which implies the user is currently in a context that has the same origin as the app publisher and also the same origin as the app invocation URL.

This context is highly likely to be the user's online banking website or the website of their chosen wallet provider. It could be the merchant's website but only in the case where the merchant has a payment app.

tommythorsen commented 8 years ago

I quite like this suggestion. The problem with PaymentApp.register() is that users are not very likely to install payment apps ahead of time. Even if the user goes to the web site of his bank, and this web site offers to install a payment app into his browser, he is most likely to think "hmph, why would I need that? I have nothing that I plan to pay for online." Most people will probably not be interested in installing a payment app until the very moment they actually need to buy something.

We've discussed having merchant recommended apps, but what this issue suggests is to ditch the installation part and only consider the list of apps supplied by the merchant (which will then need to contain enough information to actually launch the payment app). This will probably work very well for proprietary payment methods, which I would argue are probably the majority of payment methods. The only open payment methods I can think of right now would be basic card payments and probably most cryptocurrencies.

If we go for this suggestion, many of the problems we are currently discussing will go away. For instance, there will be no need for a query function, which is functionality that many people are against, for privacy reasons.

The open question here is: if we want to go this route, how do we deal with open payment methods? One approach might be to go for a combination, where we leave the PaymentApp.register() function (or something similar to it) intact, but make it optional for proprietary payment apps.

ianbjacobs commented 8 years ago

@adrianhopebailie wrote:

"I believe this issue ignores the fact that most payment apps will not be registered as part of the checkout flow."

This thread has shed light on a design consideration [1] that we expect registrations to happen both in checkout (e.g., merchant-recommended apps) and out of checkout (e.g., while browsing an app provider side). I've updated the design considerations doc with some use cases. It's useful to call that out in the spec. It's not yet clear to me whether there are any functional implications for the API.

"The PaymentApp.register() function will be called by payment app publishers and we have said we want to enforce origin based security which implies the user is currently in a context that has the same origin as the app publisher and also the same origin as the app invocation URL."

I agree that it will be useful to be aware of origins. This may affect a number of things, including:

[1] https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#design-considerations

sideshowbarker commented 8 years ago

The merchant specifies which payment apps (as well as methods) it supports -> UAs display the list (they can sort based on how that customer has interacted with those apps in the past if they want)

Yeahs, that’s essentially what UAs are already doing (based on their current autofill mechanisms).

sideshowbarker commented 8 years ago

It seems like the whole concept is just adding complexity to the customer experience

Yes, and given the whole point of this work from beginning has been to reduce the complexity of the user experience, anything that requires additional work from users should be added only if it’s clear that it’s absolutely essential. And it’s not clear that payment-app registration is essential.

halindrome commented 8 years ago

Yes, and given the whole point of this work from beginning has been to reduce the complexity of the user experience, anything that requires additional work from users should be added only if it’s clear that it’s absolutely essential. And it’s not clear that payment-app registration is essential.

I agree that is the goal. But our use cases make it clear (to me) that third party Payment Apps must be supported. And if that is the case, there must be a way to let the system know they are available. That has nothing to do with the user or user complexity. It isn't as if the user is typing PaymentApp.register(string, callback). The user clicked install on the Wells Fargo payment app while they were looking at their checking account balance. That interaction needs to work seamlessly.

sideshowbarker commented 8 years ago

I agree that is the goal. But our use cases make it clear (to me) that third party Payment Apps must be supported. And if that is the case, there must be a way to let the system know they are available.

As noted in other comments, browsers already have a way to know automatically what payment methods are available, without users needing to do anything additional beyond what they are already doing. From the user perspective, it just works.

halindrome commented 8 years ago

If there was another discussion about this somewhere and I missed it, I apologize.

I think it is true that in a closed ecosystem some browsers may have a way to know what payment methods they are managing themselves when they are also acting as a payment app. That's a solved problem. Or if it isn't, I am confident that the browser developers can solve it themselves.

I don't think that we have addressed the concern of third party payment apps. In particular on non-mobile platforms. There is no native way to register a payment app on Linux, for example. In a Linux environment, the payment app will be attached to the user agent somehow. Windows on the desktop should have a similar need.

I am not against the typical case being seamless. I think that is essential. But as a standards body we can't create a system where it isn't possible for everyone to participate. At least, I don't think we can.

ianbjacobs commented 8 years ago

I believe we have closed this particular issue by adding text to the payment app spec. We have, I believe, answered Jason's question.

There are other registration issues (what data to provide, enforcement of origin considerations, etc.) but those can be addressed under separate issues.

Ian