Skip to content
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

Clarify the concepts of enabled vs. supported #132

Merged
merged 2 commits into from
Jun 1, 2016

Conversation

tommythorsen
Copy link
Member

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

See the discussion in #110.

Try to clarify what supported and enabled payment methods really mean,
and in what situations they apply.
specification</a> for that payment method.</p>
<p>A <a>user agent</a> SHOULD NOT define a payment method as <a>
enabled</a> unless one of the following criteria is met:
</p>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it mean for a user agent to define a payment method as enabled? The user agent doesn't know anything except what the payment app tells it during registration.

Copy link

@webpayments webpayments May 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, that's a typo. That's supposed to say "payment app", not "user agent" I'll fix that when I get to a computer.

@ianbjacobs
Copy link
Contributor

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
Copy link
Member Author

@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
Copy link
Collaborator

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
Copy link
Member

👍 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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member Author

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.

@tommythorsen tommythorsen merged commit f0544f3 into w3c:gh-pages Jun 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants