search

w3c / webpayments

The document repo for the Web Payments Working Group
https://github.com/w3c/webpayments/wiki
Other
257 stars 63 forks source link

Clarify the concepts of enabled vs. supported #132

Closed tommythorsen closed 8 years ago

tommythorsen commented 8 years ago

Try to clarify what supported and enabled payment methods really mean, and in what situations they apply.

See the discussion in #110.

ianbjacobs commented 8 years ago

Please have a look at the set of definitions here: https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#definitions

I believe they will all be useful, and we should expand the section beyond "enabled".

It would be fine by me (indeed desirable) to pluck the definitions from the wiki and put all of them in the spec.

Ian

tommythorsen commented 8 years ago

@ianbjacobs

I believe they will all be useful, and we should expand the section beyond "enabled".

I have added the "unsupported" state from the wiki page

It would be fine by me (indeed desirable) to pluck the definitions from the wiki and put all of them in the spec.

That sounds good to me, but I would like to do this in separate PRs. Maybe a good first step could be to go through the wiki page and make an issue for each category of definitions. I can try to do that on Monday.

adrianhopebailie commented 8 years ago

It would be fine by me (indeed desirable) to pluck the definitions from the wiki and put all of them in the spec.

👍 - I have been meaning to do this for a while. Will submit a PR now with definitions that will help us to make the language later on in the spec clearer.

jnormore commented 8 years ago

:+1: to the changes.

As an aside, this brings up the thought to me of whether or not both 'supported' and 'enabled' are really necessary because if I were a payment app I would say 'enabled' for everything that I support because I want to provide the best experience and to ensure I capture as many new customers as possible by having a seamless onboarding flow within the payment experience. I'll admit though that I'm probably not thinking of some payment apps that require a separate onboarding process that's impossible inside the payment flow, but from a customer perspective that wouldn't be a great experience anyway. A PR is not the appropriate place to discuss this, I'll open an issue after thinking it through a little more.

ianbjacobs commented 8 years ago

@jnormore wrote:

"whether or not both 'supported' and 'enabled' are really necessary because if I were a payment app I would say 'enabled' for everything that I support "

I think we should keep the states in order to allow different apps to offer different experiences. I think apps should be allowed to function as you describe. But some might not want to do that and should have the state data to make the decision themselves.

Ian

fredMeignien commented 8 years ago

There is an issue somewhat related to the question of "unabled/supported" : in the world of card payments, there are regulations which impose to the merchant to let the customer choose his card application : this is especially the case for "debit" and "credit" card: the customer should be proposed the possible options in order to let him choose the option implying the cheapest fees. This is the best known example, but there are many other cases of this type. Apart from regulations, there are quite agressive marketing policies from the card networks to promote the use of this or that brand; for instance, one brand will propose loyalty for a certain category of merchant, and then the customer will be interested in preferring the related card. Or, the merchant will promote a certain sub-brand because the related fees may be more interesting for him. All this implies that the mediator has to implement, among the enabled payment methods, the possibility of a "guided" choice. It is not just selecting the "default" card, for instance, because a Visa card may be default for a certain type of payment, whilst the Mastercard of my wallet may be the default for another type of payment. Even though, in first approach, all this may be considered as extra sophistication, I think that we should keep those requirements in mind in designing the architecture of the mediator.

jnormore commented 8 years ago

I think we should keep the states in order to allow different apps to offer different experiences. I think apps should be allowed to function as you describe. But some might not want to do that and should have the state data to make the decision themselves.

Agreed, I more wanted to highlight the point that I think it will be most common for apps to treat them the same. I also think that 'supported' in the current spec is the same as the 'recommended' apps concept that we've discussed, recommended is just a UI concept that displays the supported list that aren't enabled, meaning that we'd still need the concept of 'supported' to have recommended apps. Does this align with your thinking?

tommythorsen commented 8 years ago

Seems like people are generally positive to merging this. If you want to keep discussing this, opening an issue might be nice. I have been making some of the same points in #110, but that issue is getting long and convoluted. A new issue might be better.