Re: [w3c/webpayments-method-identifiers] Resolve whether browsers need to police payment app claims of supported methods (#11)

@zkoch,

I can understand if this statement (emphasis mine) is more than just conjecture, but I would find it a little surprising. Is it more than conjecture?:

> If we can't prevent [arbitrary payment apps for claiming support for proprietary payment methods], **we're going to have a hard time convincing existing players to enter into our ecosytem**, which makes adoption by merchants more difficult.

Anyone can claim whatever they want, but I gather that you're talking about that claim translating into the app actually showing up as a choice. But it seems like the only time this extra protection would have an effect would be when no open methods are offered by the merchant, right?

Isn't it more likely that merchants will offer at least one open way (e.g. basic card) to pay? Certainly many will. If a merchant offers, for example, both PayPal and basic card, then any protection mechanism implemented for proprietary methods will be ineffective, as options will appear for both mechanisms, including any bogus options from disreputable apps.

If the user has indicated that they only want to use a particular app for PayPal and they've indicated a preference for PayPal over basic card, then I would expect that the choice screen could be skipped; but this approach works for both open and proprietary mechanisms.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-method-identifiers/issues/11#issuecomment-241062855

Received on Friday, 19 August 2016 16:16:36 UTC