Re: [Payments Architecture] A vision statement for the web payments architecture work

RE: "I thought that singling out ... business models might be
counterproductive"

+1

Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Thu, Jun 4, 2015 at 7:14 AM, Pindar Wong <pindar.wong@gmail.com> wrote:

>
>
> On Thu, Jun 4, 2015 at 6:18 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> Hi Pindar,
>>
>> Thanks for the feedback. I think the purpose of that phrase is to
>> specifically highlight the fact that the majority of internet businesses
>> are dependent on advertising revenue. Making payments on the Web more
>> efficient and lowering their cost will make a number of new revenue models
>> possible (financially viable).
>>
>
> Thank you Adrian for your prompt reply and for raising the point above.
>
> On my first read, that was indeed how I interpreted this bullet point and
> I considered it in a positive light, as you have, in drawing attention that
> is the advertising model is what is currently known to work. It has indeed
> been the basis for business models for a number of 'free' services, a model
> where users 'pay' in data and in terms of their privacy. A point that is
> also amplified by the earlier 'Web principle' of 'Protecting the privacy of
> all participants'
>
>
>> I would argue that calling out advertising as the only viable revenue
>> stream on the Web today is not a bad thing on the basis that I don't
>> believe these new business models will succeed at the expense of ad-revenue
>> based business. Rather, they will simply divert more consumer and business
>> spending to Web-based as opposed to traditional businesses. Would you agree?
>>
>
> I think that advertising has its own valuable role in certain
> circumstances. It has enabled the web to succeed thus far and we should be
> mindful of that, though we may disagree with how invasive their profiling
> has become.
>
> However, on second read, I thought that singling out advertising business
> models might be counterproductive in terms of getting buy-in or
> participation in our payments work, notwithstanding that I don't think that
> it is in entirely in keeping in document at the level of a 'vision
> document'.
>
> Specifically,  I would refrain for any perception of prejudicial bias
> against advertising or advertisers. If only to help with transitioning from
> the existing model to any future model that web payments might enable.
>
> Perhaps in light of your points above, I might soften that statement with
> the addition of 'only' to read:
>
> 'This is key to opening up new revenue generating opportunities on the Web
> that do not depend only on advertising.'
>
> Thank you for considering this matter for whatever it may be worth, and I
> apologize for laboring this point.
>
> Regards,
>
> p.
>
> PS: Tomorrow I'm presenting at *http://fintechinnovation-asia.com/*
> <http://fintechinnovation-asia.com/> and will be mentioning the fine work
> of the CG and IG.
>
>
>
>> Adrian
>>
>>
>> On 4 June 2015 at 04:51, Pindar Wong <pindar.wong@gmail.com> wrote:
>>
>>> Dear Adrian,
>>>
>>> I note that the IG Chair has issued a call for consensus on the vision
>>> document
>>> <https://lists.w3.org/Archives/Public/public-webpayments-ig/2015May/0220.html>on
>>> the 28th May.
>>>
>>> I've taken another quick look here
>>> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision
>>>
>>> and note that with respect to the 2nd last bullet, '*Enables
>>> monetization on the spectrum of Web to native apps*. Web developers
>>> will be able to integrate payments smoothly into a variety of user
>>> experiences on the Web, including in-app payments, downloads, and
>>> subscriptions. This is key to opening up new revenue generating
>>> opportunities on the Web that do not depend on advertising.'
>>>
>>> I might suggest that at the face-to-face meeting later this month that
>>> you consider amending this to delete the tail section that reads' that do
>>> no depend on advertising' if only to avoid unnecessary alienating a priori
>>> this other community.
>>>
>>> i.e. In other words I think it wise to just leave it at:
>>>
>>> *Enables monetization on the spectrum of Web to native apps*. Web
>>> developers will be able to integrate payments smoothly into a variety of
>>> user experiences on the Web, including in-app payments, downloads, and
>>> subscriptions. This is key to opening up new revenue generating
>>> opportunities on the Web.
>>>
>>> Regards,
>>>
>>> p.
>>>
>>>
>>>
>>> On Fri, May 22, 2015 at 11:36 PM, Adrian Hope-Bailie <
>>> adrian@hopebailie.com> wrote:
>>>
>>>> Thanks Pindar, I agree with sticking to the standard actors of payer
>>>> and payee.
>>>>
>>>> On 22 May 2015 at 17:34, Pindar Wong <pindar.wong@gmail.com> wrote:
>>>>
>>>>> Dear Adrian, all,
>>>>>
>>>>> Sorry for my late reply, but as far as the last bulletpoint, [
>>>>> *italics* mine]
>>>>>
>>>>> *Bridges distributed value networks*. The Web will ultimately serve
>>>>> as a bridge between both open and closed value exchange networks, enabling
>>>>> ubiquitous and easier payments. This will enable both *merchants* and
>>>>> *customers* to seamlessly send and receive money using a variety of
>>>>> previously non-interoperable payment instruments.
>>>>>
>>>>> I've probably missed something, but I read this 'bridging' aspect to
>>>>> focus on interoperability of value exchange networks, and suggest for your
>>>>> consideration that this section be reworded to:
>>>>>
>>>>> *Bridges distributed value networks*. The Web will ultimately serve
>>>>> as a bridge between  open and closed payment networks, enabling
>>>>> interoperable value exchange. This will enable both* payers *and
>>>>> *payees* to seamlessly send and receive value using a variety of
>>>>> previously non-interoperable payment instruments.
>>>>>
>>>>> m2v ;)
>>>>>
>>>>> p.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 22, 2015 at 9:27 PM, Adrian Hope-Bailie <
>>>>> adrian@hopebailie.com> wrote:
>>>>>
>>>>>> Hi Antonio,
>>>>>>
>>>>>> After reading the current version of the document, I have some
>>>>>>> comments and suggestions that I would like to share. I hope they are useful.
>>>>>>>
>>>>>>
>>>>>> Thanks for your input
>>>>>>
>>>>>>
>>>>>>> - Regarding user experience, I would mention that the payment
>>>>>>> process (initiation, purchase, obtaining a receipt and the product/service)
>>>>>>> should be uniform so that the user can see the process is conducted in the
>>>>>>> same way and, thus, it generates trust to the users. I do not know if this
>>>>>>> is what you want to mean with "harmonizing the checkout experience across
>>>>>>> e-commerce websites."
>>>>>>>
>>>>>>
>>>>>> Yes, this is what that sentence is intending to say. Perhaps
>>>>>> "harmonizing the payment experience across all Web applications and sites."
>>>>>>
>>>>>>
>>>>>>> I would also include that it should facilitate that the user can
>>>>>>> know the payment options available and even the (automatic) negotiation of
>>>>>>> these options.
>>>>>>>
>>>>>>
>>>>>> Is this not covered under the bullet: "*Provides payees and payers
>>>>>> unencumbered knowledge and choice in how to undertake payments*"?
>>>>>>
>>>>>>
>>>>>>> - I would also incluse some comment on that the way of making the
>>>>>>> encapsulation of (new or existing) payment schemes should be uniform and
>>>>>>> independent of the type of payment scheme (mobile or not).
>>>>>>>
>>>>>>
>>>>>> I think this is implied by the fact that we are "standardizing" this
>>>>>> process.
>>>>>>
>>>>>> - From my point of view, I do not why know why the document needs the
>>>>>>> bullets "Enables monetization on the spectrum of Web to native apps" and
>>>>>>> "Bridges distributed value networks should part of the vision.". From my
>>>>>>> point of view, these issues are a consequence of "Encapsulates existing
>>>>>>> payment schemes and enables new schemes. "
>>>>>>>
>>>>>>
>>>>>> No, the first bullet you mention is explicitly talking about enabling
>>>>>> new business models on the Web due to the reduction in friction and cost of
>>>>>> payments (monetization). This speaks to things like enabling
>>>>>> pay-per-click/read/watch/listen media consumption or
>>>>>> similar which can't be easily done today because the way payments are
>>>>>> processed makes these business models non-viable.
>>>>>>
>>>>>> The second is explicitly calling out the need for the architecture to
>>>>>> allow payers and payees to make a transfer of value between one another,
>>>>>> even if they don't have a common payment instrument or scheme. i.e. The Web
>>>>>> must work like the Web is supposed to and have a mechanism to fill the gaps
>>>>>> and comment the two.
>>>>>>
>>>>>>
>>>>>>> - As for security and privacy, the sentences that mention "Supports
>>>>>>> a wide spectrum of security requirements and solutions" or similar should
>>>>>>> be reworded. Why a "wide spectrum"?. I consider that the security, privacy
>>>>>>> and regulatory issues have to be taken into in the development of an
>>>>>>> e-commerce website or e-payment solution. However, I consider that, e.g.,
>>>>>>> the support of different authentication mechanisms is not part of the
>>>>>>> payment architecture. However, in the processes that are part of the
>>>>>>> payment process, for example, getting a payment offer, the payment
>>>>>>> architecture should define the mechanisms to protect this information.
>>>>>>> Then, I consider that in the bullet we could say that security, privacy and
>>>>>>> regulatory issues will be taken into account to design the different
>>>>>>> process of payment architecture that need to be securized.
>>>>>>>
>>>>>>>
>>>>>> Our intention is to propose an architecture and ultimately define
>>>>>> some standards. When it comes to regulation and security I think our
>>>>>> approach is to cater for everything we know is out there but not prescribe
>>>>>> how implementations are built. When it comes down to an implementer
>>>>>> deploying a solution in a specific jurisdiction subject to specific laws
>>>>>> and regulations they should not be restricted by the architecture in trying
>>>>>> to adhere to these. On the other hand the architecture should describe at
>>>>>> what points these issues come into scope and provide mechanisms to deal
>>>>>> with them so that we make the life of the implementer easier.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Best regards,
>>>>>>> Antonio.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El 18/05/2015 a las 14:58, Adrian Hope-Bailie escribió:
>>>>>>>
>>>>>>>> The IG are trying to finalize a short vision statement for the work
>>>>>>>> we
>>>>>>>> are undertaking, specifically with regards to the architecture we
>>>>>>>> will
>>>>>>>> be developing, for payments on the Web.
>>>>>>>>
>>>>>>>> The document is intended to express the technical principles we
>>>>>>>> consider
>>>>>>>> important in the design of the architecture and I'd appreciate some
>>>>>>>> input on it's content.
>>>>>>>>
>>>>>>>> The document is also intended to be short, less than a page, and as
>>>>>>>> such
>>>>>>>> not too detailed. It's purpose is to frame the design and allow all
>>>>>>>> stakeholders to agree up front that we are aligned on our vision.
>>>>>>>>
>>>>>>>> The audience should be broad, and not necessarily payments or Web
>>>>>>>> technology experts, but since this is related to the design of a
>>>>>>>> technical architecture the content will be technical.
>>>>>>>>
>>>>>>>> Please have a look at the first draft of this document and send me
>>>>>>>> your
>>>>>>>> feedback.
>>>>>>>>
>>>>>>>> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Adrian
>>>>>>>>
>>>>>>>> p.s. Thanks Ian Jacobs for the initial work in getting this started.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --------------------------------------------------------
>>>>>>> Antonio Ruiz Martínez
>>>>>>> Department of Information and Communications Engineering
>>>>>>> Faculty of Computer Science-University of Murcia
>>>>>>> 30100 Murcia - Spain
>>>>>>> http://ants.inf.um.es/~arm/ or http://webs.um.es/arm/
>>>>>>> e-mail: arm@um.es or arm [at] um [dot] es
>>>>>>> --------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


--