Merchant Adoption Strategy

<Ian> Adoption2017 wiki

Ian: My understanding from implementers is that there are a lot of conversations havening already about adoption for the API
... good to hear challenges to adoption
... getting starting in the ecosytem is one
... merchants want users, users want lots of merchants to accept this
... another is cross platform deployment
... the API supports transition; communicating to them clearly how to use the API in an ecosystem of partial adoption is an important part of our communications with them
... having a communication strategy will be helpful
... the WG is focused on the gory details but not the shiny details that appeal to other audiences who may be important to adoption

Zach: I'd agree with those
... another one is the "newness of this approach" ...internally we've called it a branding problem ...the world right now is "pay with X" ...applepay, chase pay, etc....there is a user education problem for payment request API

Ian: I agree with the branding issue and think that a recognized name and identity will be important to building trust: what will happen when I click on this button?

Javed: technical simplicity offered to merchant; consistent acrosse browsers and payment types
... outreach on the marketing side collectively

<Ian> MESSAGE: (1) technical simplicity (2) consistency

<Ian> QUESTION: What merchants to target

Mathp: I agree with Javed. I think technical simplicity is covered by the API....consistency on merchant side is something I'd like to see. What I would like to see is on the merchant side...they can choose to brand this experience however they want "instant checkout" or "express checkout"
... there is no indication to the user that they are now using the API
... there is no education for the user...
... guidance here for merchants would be helpful
... I hesitate to call it branding
... suggested presentation of the buttons

Ian: Engaging users to payment apps isn't a priority topic but part of the value proposition of this ecosystem. Let's review the goals in the wiki:

<Ian> Raise awareness about Payment Request API and encourage merchant adoption.

<Ian> Gauge interest in merchant payment apps

Ian: Any ideas on reaching merchants differently?
... As far as audience
... two questions
... are we really thinking about convincing the strategists, in companies, or the developers, or both. Big or small merchants or all? ... would it be more effective to do demos to developers?
... or show people shiny experience?
... given limited resources, I'd like to prioritise

Zach: I view this as "what can the WG do to empower developers" but also the teams inside of companies so that collectively we provide tools to aid in those conversations. +1 to the second half of what you're proposing. Answer questions like "how to deal with coupon codes?" Share info about common ux patterns. We should put up tools, offer advice on branding/identity. At google we have sample code and integration guide but it would be good to show a collaborative effort among vendors. Developers need example codes, but they aren't the one who need to be convinced. We need to convince CMOs and product owners.

Alan: I'd agree with Zach
... perhaps we should think in terms of event
... or time-frame
... a goal we share: e.g. interop
... good milestone. Perhaps a one-time event to raise awareness --- some interop among browsers and apps; have a marketing event around that.

Andrew: I'm on the BD team
... a challenge we're facing. A larger education effort
... shop talk, March 19, is a big event coming up
... to introduce what we're working on

Ian: When at Money 2020, I asked and heard it was too late already for Shop Talk
... maybe a collective effort might encourage us for a panel, for example
... I will also be speaking with people at Money 20/20 which might be an option for our collaborative effort
... I'll keep up these conversations
... state of implementation and interop might determine which event is better.

Ian: I'm hearing that product owners is the place we should prioritise
... it may involve materials for developers

<adamR> +1

<MaheshK> +1

<kayakalan> +1

Ian: What about merchant size?
... big small, any size?
... it's great that shopify is in the group
... could help us reach merchants quickly
... other names were suggested to me
... any others would help us achieve scale in this effort?

Adam: We could grab someone like Amazon
... that would be a high profile
... we have reasonable contacts

Ian: It would be great indeed. I'm in conversation with several big (US) merchants. It would also be valuable to have some non-US merchants. A big visible merchant would help.
... any other thoughts on what size merchant would be most amenable to this
... or what could we help you do that outreach?
... what could we produce?

Javed: We can target tier-one merchants
... that would get us to scale
... and bring attention to the broader industry
... we need to show that it's not individual but a bigger scale that merchant investment would benefit. Our marketing documentation should show brands of participants in the WG; that this is an investment and will scale.

<Ian> MESSAGE: Once you implement this you can reuse across new payment methods

Javed: We should also provid information about (1) when the API will be supported (2) on which devices and systems (3) which payment methods are likely to be supported. If we can collectively give a bigger message, beyond individual road-maps, and send the messages that there's a commitment to future suport, that would have an impact. Let people know that these are early days, but there's a commitment to this and implementations are underway and some things are already supported. This is an investment that will lead to success over time.

Ian: great, thank you

Mathieu: I agree completely
... as we write, it doesn't make sense for each of us to rewrite our own versions
... let's write it collectively
... "here's what supported now and what is coming"

Ian: Thank you
... what do you label that sort of resource?

Mathieu: maybe a website that is on GitHub
... that people contribute to
... share code
... "such and such browsers added support for payment"

Ian: code sample and business cases and implementations are helpful

<Ian> IJ: w3.org or some other domain?

<Ian> AdamR: I think the people who will work on this will be different and from that perspective does not need to be closely associated with the WG A new domain may help.

Ian: not a big deal from an admin perspective, but the least maintenance the better
... trying to gauge what people think
... how serious marketing do we need

Mathieu: +1 to GitHub
... I'm not an expert in marketing but custom domain is probably preferable than github.io
... in terms of collaboration, GH is great

<mathp> adamR: Github pages doesn't support HTTPS certs for custom domains, but +1 to GitHub source control.

<adamR> mathp: There’s a… partial solution. It’s not awesome, but still pretty good: https://konklone.com/post/github-pages-now-sorta-supports-https-so-use-it#using-a-custom-domain-with-cloudflare

<adamR> mathp: (Requires attackers to effectively be in network core or on premise at cloudflare or github)

Adam: there are ways to host domains on Github

<mathp> adamR: Thanks

Ian: if we acquire such a resource, we need to figure out a plan for it
... I'd turn to those present to find out about committment levels
... Coralie Mercier, head of marcomm is on the call today
... we could start to build a plan and circulate it among the WG
... develop it in e-mail or on calls

Thao: given we are talking to early adopters at this point
... a single slide, just to give a sense of where that stands in the various browsers
... and links
... for now
... we may want to convert it to a website later
... all of use can use that slide with our respective logo

Ian: I had started to put together a public common space in the WG's wiki, but a more structured approach could be more interested
... people would need to give us update
... lest it's outdated

<Koalie> I wanted to say that I'll be happy to include plans in the broader web payments communications plan and strategy. +1 to GitHub rather than starting with a new domain name.

Ian: we could start simply
... and find we may want to package it differently

[Coralie: +1]

Ian: do people think a name would help to talk about it in a consistent way?

<rouslan> +1

<MaheshK> +1

Alan: Who woud be interested in an event or cross-interop demo?
... that's when critical mass will happen
... with this initiative
... re: name and logo
... name is first before visual identity
... we call it W3C pay internally and to partners
... for lack of a better name
... then get a logo if you can
... start slow

<Ian> ===

<Ian> summarizing some shorter term tactics

<Ian> * Web site with useful resources

<Ian> * Name to call this thing

<Ian> * An event (for late Q2 2017 at the earliest)

<Ian> * Status information

<Ian> * Highly visible adoption

<Ian> (status = implementation + adoption)

======

Ian: any other things people had in mind?

Mathieu: great list. We need to be able to contribute now

Ian: 'name to call this thing' isn't the domain name we may choose
... what do we call it from a marketing perspective
... then what do we do to support it

<mathp> mathp: will have to think about names! Good homework :)

Next call

<Ian> 3 Feb at noon ET for 1 hour

<MaheshK> +1

<Ian> ACTION: Ian to set up a w3c mailing list for discussions about this topic [recorded in http://www.w3.org/2017/01/20-wpwg-minutes.html#action01]

<Ian> ...and subscribe people on this call to that list

<Ian> ...and tell the WG about it

Ian: shall we find a GH repo?
... or use the existing vision wiki

<mathp> Not familiar with existing repos...

<Ian> https://github.com/w3c/webpayments/wiki/Adoption2017

Ian: or wiki on gh
... where the WG people have write access
... people can start collaborating, including ideas for names

<Ian> ACTION: Ian to send around meeting logistics [recorded in http://www.w3.org/2017/01/20-wpwg-minutes.html#action02]

Ian: Thanks everybody
... it's been helpful