W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

Re: [w3c/webpayments] Clarify the concepts of enabled vs. supported (#132)

From: fredMeignien <notifications@github.com>
Date: Tue, 31 May 2016 08:56:11 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>, Comment <comment@noreply.github.com>
Message-ID: <w3c/webpayments/pull/132/c222733891@github.com>
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 jus
 t 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.

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/pull/132#issuecomment-222733891
Received on Tuesday, 31 May 2016 15:56:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 31 May 2016 15:56:55 UTC