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

Re: [w3c/webpayments] [Payment Request] Should we allow a "polling" mechanism for websites to not invoke the API if there are no enabled methods (#159)

From: Jason Normore <notifications@github.com>
Date: Tue, 12 Jul 2016 06:32:58 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>, Comment <comment@noreply.github.com>
Message-ID: <w3c/webpayments/issues/159/232048158@github.com>
> That's Bob's job.  Not mine.

I think this is where the difference in opinion is. This is just as much the merchants job as it is Bob's. The merchant wants the customer to have the ability to check out as easily as possible, to sell their products, so it's their job to give them the most seamless way to onboard to those payment methods as possible while not distracting from the original intent to purchase. More than 90% of checkouts on our platform are new customers/new devices/new accounts, which would fall into this first-time experience flow for a lot of payment methods. Not all merchants are major marketplaces, once you get to individual SMBs or even larger merchants with standalone sites return rates are much lower, for example I shop at Amazon almost daily but I shop at Nike maybe only a couple times a year (or whatever shoe store). You can argue that by shopping at one site and setting up your payment method there, the customer no longer has to worry about this on others, but there are a lot of different payment methods out there and new customers/devices/accounts all the time, the first-time experience is more important than I think most people realize.

The case of merchants being incentivized by PSPs to offer them as a preferred checkout method is valid but not the major driver of this for me.

I didn't mean to hijack this thread for this, it's off-topic for sure :)

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Received on Tuesday, 12 July 2016 13:33:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 July 2016 13:33:33 UTC