Re: Web Payments Demo

> If I say “I always want to pay with Method X”, but a merchant who accepts
X is able to override my default selection to Y…that’s a bad user
experience. I told the user agent I always wanted to pay with X where
available. User agent preferences aren’t normally allowed to be overridden
by sites arbitrarily.

I agree. I don't think we can allow merchants to change a user's preference
within the flow of the API however we are ignoring the fact that the
merchant and user are interacting via the website before and after the
payment request API is invoked.

If a merchant wants to incentivize a user to use a new payment app or
payment method they can try to do so before the API is invoked so that the
user might change their preference during the checkout or afterwards.

On 27 May 2016 at 19:36, Nick Shearer <nshearer@apple.com> wrote:

>
> On May 27, 2016, at 9:37 AM, Telford-Reed, Nick <
> Nick.Telford-Reed@worldpay.com> wrote:
>
> An example that immediately springs to mind might be Paypal as a payment
> application – which might itself contain multiple payment methods (credit
> card, debit card, direct credit transfer from bank account). Payment method
> ≠ payment application. (Other examples of payment applications – Android
> Pay, Apple Pay, Visa Checkout, Masterpass…)
>
> >> I think the UI should not only show the one payment method that the
> browser (based on internal heuristics I guess) decides on its own should be
> the default displayed,
> >>  and bury the rest of payment-method choices in a select menu or other
> UI that requires the user manually activate a disclosure triangle or other
> UI widget to see what payment methods they can use.
>
> The other observation I’d make on Mike’s comments would be to flag a huge
> concern over the default payment app/method. Payment providers spend (in
> the case of Visa and Mastercard) Billions of dollars a year making sure
> that their payment instruments are front of wallet. I think “burying” the
> other choices will make getting support for adoption from these providers
> pretty difficult. I am anticipating that the prioritisation of payment
> applications and payment methods will be one of our most challenging design
> issues.
>
>
> There’s more scope perhaps for situations where a user hasn’t indicated a
> preference. I don’t want to play down the use case, I know it’s a very
> important one for merchants.
>
> But at the same time I think it’s a very tough argument that a merchant
> should be able to override a user’s explicit preference if they’ve set one.
> If I say “I always want to pay with Method X”, but a merchant who accepts X
> is able to override my default selection to Y…that’s a bad user experience.
> I told the user agent I always wanted to pay with X where available. User
> agent preferences aren’t normally allowed to be overridden by sites
> arbitrarily.
>
> I think you’re right that it will need further consideration, especially
> with regards to an equal benefit to the user and the merchant. I’m sure
> there’s a compromise somewhere.
>
>
> Nick
>
> *From:* Rouslan Solomakhin [mailto:rouslan@google.com <rouslan@google.com>
> ]
> *Sent:* 27 May 2016 16:54
> *To:* Adrian Hope-Bailie <adrian@hopebailie.com>
> *Cc:* Michael[tm] Smith <mike@w3.org>; Tommy Thorsen <tommyt@opera.com>;
> Ian Jacobs <ij@w3.org>; Web Payments Working Group <
> public-payments-wg@w3.org>
> *Subject:* Re: Web Payments Demo
>
> On Fri, May 27, 2016 at 6:57 AM Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>
>    - How the selection of a payment method is done by a payment app will
>    depend on the payment method. We shouldn't assume that it always means
>    selecting a payment instrument. That is a very card-centric way of seeing
>    things.
>
> What alternatives are there besides selecting a payment instrument? Please
> elaborate.
>
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>
>
>
>