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

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