W3C home > Mailing lists > Public > public-webpayments@w3.org > May 2015

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

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Tue, 26 May 2015 13:03:35 +0200
Message-ID: <CA+eFz_LwNn29sKFPRbknKSohWhzwo3XJYw9Fj+0L-himePXObQ@mail.gmail.com>
To: Antonio Ruiz Martínez <arm@um.es>
Cc: Web Payments CG <public-webpayments@w3.org>
>
>
> 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.
>

With this explanaition I understand your idea. But, from my point of view,
in the end, this is making a kind of "P2P payment", which we could consider
as a new payment scheme.

+1 Yes. I wouldn't say it has to be P2P (person to person) it could be a
business or government or any other entity on either end of the payment but
the point is we ARE suggesting that there be a new payment scheme, called
the Web. It will provide the glue between existing schemes so we have a
truly decentralized system as Melvin suggests.


On 26 May 2015 at 11:13, Antonio Ruiz Martínez <arm@um.es> wrote:

> Hi Adrian,
>
> First of all, many thanks for you comments and explanations.
>
> El 22/05/2015 a las 15:27, Adrian Hope-Bailie escribió:
>
>> 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."
>>
>
> it sounds ok.
>
>
>>     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*"?
>>
>
> May be.
>
>
>>     - 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
>>
>
>
> This last explanation is clearer since the previous one, in my opinion, do
> not involve something clear related to the defintion of the payment
> architecture.
>
>  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.
>>
>
> With this explanaition I understand your idea. But, from my point of view,
> in the end, this is making a kind of "P2P payment", which we could consider
> as a new payment scheme.
>
> Best regards,
> Antonio.
>
>
>>     - 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 <mailto:arm@um.es> or arm [at] um [dot] es
>>     --------------------------------------------------------
>>
>>
>>
> --
> --------------------------------------------------------
> 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
> --------------------------------------------------------
>
Received on Tuesday, 26 May 2015 11:04:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:40 UTC