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

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
>>>> --------------------------------------------------------
>>>>
>>>
>>>
>>
>