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

Re: [payment arch] Negotiation of payment terms

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Mon, 11 May 2015 15:59:00 +0200
Message-ID: <CA+eFz_+64gH_oGJ7D9fsJ-=VmRNBbPg3OWfYez0ZeLizM=Zowg@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: "public-webpayments-comments@w3.org" <public-webpayments-comments@w3.org>, Web Payments CG <public-webpayments@w3.org>
Hi Anders,

Have a look at the architecture document. The payment agent is an abstract
concept at this stage describing a service that is a broker between an
entity, the accounts they hold and other agents. Exactly where it is
implemented will vary.

In the user agent scenario I expect it will be either a browser extension
or built into the browser itself. It may become a built in part of the
operating system, that is up to the implementors.

I expect there will be FOSS implementations that can be run locally or
remotely under the user's direct control and proprietary implementations
provided by stakeholders in the networks such as account custodians or
payment providers.

Adrian

On 11 May 2015 at 15:10, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2015-05-11 15:04, Adrian Hope-Bailie wrote:
>
>> As we work on the design of the web payments architecture (
>> https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit)
>> I want to discuss the flow a little, where payment agents fit in and which
>> interfaces are used for which messages specifically for the offer and
>> negotiation of terms.
>>
>> It seems that initiating the payment through the transfer of an offer
>> message to the payer is the most likely trigger. Do we forsee this offer
>> being passed to the payer's payment agent via the command/user interface or
>> via the agent-to-agent interface or both?
>>
>> Imagine the use case where I am on the internet browsing an online store.
>> When I visit the checkout page the site delivers an offer to my browser
>> which the browser forwards to my payment agent. My payment agent begins
>> interacting directly with the store's payment agent and the flow continues.
>> Alternatively the site delivers a URL pointing to the site's payment agent
>> and including a reference to the offer.
>>
>> I prefer the latter as it keeps the command interface very simple. There
>> would simply be a method like startTransaction(URL paymentAgentUrl) which
>> can be used for almost any scenario.
>>
>
> Is this something you imagine would be implemented in browsers?
> If so, how is that supposed to interact with wallets?
>
> Anders
>
>
>> What do you think? Does the command interface (user to payment agent)
>> need to understand the higher level flows?
>>
>> On 11 May 2015 at 14:48, Adrian Hope-Bailie <adrian@hopebailie.com
>> <mailto:adrian@hopebailie.com>> wrote:
>>
>>     @Joerg: In many scenarios a "primed wallet" is ideal because of the
>> speed and the lower number of back and forth messages required in the
>> negotiation.
>>
>>     Personally, if you are online and the processes are automated by
>> "primed" configuration (i.e. you have set up limits and preferences so that
>> your payment agent can execute most negotiations without your input) I see
>> no issue with many messages being passed back and forth.
>>
>>     A long negotiation is only a problem in the "brick and mortar"
>> scenario and how big of a problem it is I consider up for debate. If we
>> consider that the likelihood of what we develop being rolled out in the
>> physical world in probably 5 years it's also very likely that the
>> instruments and in-store technology will have changed dramatically.
>>
>>
>>     On 11 May 2015 at 14:02, Adrian Hope-Bailie <adrian@hopebailie.com
>> <mailto:adrian@hopebailie.com>> wrote:
>>
>>         I think there are two topics at hand here, linking value networks
>> and the offer negotiation. They are somewhat related but I think worth
>> discussing in depth. I think the offer negotiation has particular relevance
>> to the architecture document that we're working on.
>>
>>         I will respond with a different subject to split the thread.
>>
>>         On 11 May 2015 at 13:52, <Joerg.Heuer@telekom.de <mailto:
>> Joerg.Heuer@telekom.de>> wrote:
>>
>>             Hello Adrian,
>>
>>             Your points are taken. I like the idea to call a third party
>> in case of no match. We need to see how these things would be represented.
>> I would think it’s going to be another ‘instrument’ in both participants
>> portfolio in the end (which would be fine, because I believe it’s important
>> to boil everything down to the same pattern for transparency and so…)
>>
>>             Privacy aspects are in the very core of our aspirations. I
>> think we came out with a pretty cool schema to solve similar situations:
>>
>>             Dude has been to the rug shop a few times before, so he knows
>> that this loyalty cards would be accepted. Also, his decision to  buy the
>> rug today has been influenced by a coupon campaign put out by the shop last
>> weekend and he downloaded a 5% coupon into his wallet.
>>
>>             After having made his pick, dude ‘primes’ his wallet with a
>> payment card (he thinks is applicable) plus the loyalty card and the coupon.
>>
>>             When approaching the payment terminal all these items are
>> made available for the payment terminal  - but only those, not any of the
>> rest of the content in the wallet.
>>
>>             We got good feedback on the privacy – but especially for
>> supermarket scenarios with all those coupons, people liked the idea to make
>> everything ‘ready for action’ while standing in the line – as long as the
>> more ‘interactive’ variant to communicate with the salesperson was still
>> possible. Also, this selection process could be supported by the payers
>> wallet application using pre-defined rules, contexts, down to location or
>> beacons. Important was only that the selection made was presented to the
>> user first, before the actual transaction was started.
>>
>>             The same mechanism came to my mind in case the user doesn’t
>> know what the payment terminal will support, but wanting to be really
>> quick. Just pick a VISA, a MasterCard and a direct debit mechanism and let
>> the merchant decide. Wouldn’t be my ideal, but if you are in a hurry… I
>> would leave it as an option, because it fits the overall interaction
>> patterns. But I see potential for problems, though. Our experience says: if
>> it fits the overall pattern, make it possible and see when and where
>> players in the ecosystem make use of it. Loyalty and coupons will be okay
>> with it. If Generation of a token costs money, your wallet will have ways
>> to keep multiple ones being generated without need.
>>
>>             Cheers,
>>
>>             Jörg
>>
>>             *From:*Adrian Hope-Bailie [mailto:adrian@hopebailie.com
>> <mailto:adrian@hopebailie.com>]
>>             *Sent:* Montag, 11. Mai 2015 13:25
>>
>>
>>             *To:* Dan Schutzer
>>             *Cc:* Heuer, Jörg; Joseph Potvin;
>> public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>
>>             *Subject:* Re: Linking Value Networks
>>
>>             I don't think that the payer should send the schemes or
>> instruments they have available to the merchant. This seems like a privacy
>> problem to me.
>>
>>             I like the idea that the offer includes payment options (and
>> these could have different currencies and prices for different schemes or
>> instruments).
>>
>>             I think that if the payer sees the offer and wants to pay
>> some other way or doesn't have a supported instrument they can call out to
>> some proxy to be the intermediary. I.e. as the payer I make requests to a
>> payment provider with whom i have an account by sending them the details of
>> the offer. They go out and find the cheapest way to pay and then come back
>> to me with a request for authorisation to use the payment instrument of
>> mine that they have selected.
>>
>>             I can choose, if I am an advanced user or have some clever
>> software to do it for me, to perform the work of the payment provider
>> myself.
>>
>>             The problem with the current scenario is that the payer and
>> payee are always negotiating a way to take the payment off the Web. Finding
>> a common scheme means finding a way to settle the value exchange on a value
>> exchange network they are both a part of.
>>
>>             This should work like the Web. We shouldn't both have to be
>> in the same value exchange network if we can find others to proxy between
>> us. That is truly value exchange at Web scale as opposed to some new
>> messaging on top of the existing status quot.
>>
>>             I started writing a stupid/humerous "script" of a real world
>> payment to try and eke out the messaging requirements. I started with the
>> real world and then started adding the blue text to describe the technical
>> requirements. What's interesting is that the conversation (real-world)
>> changes a lot when you start to worry about things like privacy and trust.
>>
>>             Let me know what you think and feel free to copy and re-use
>> for a different scenario:
>>
>> https://docs.google.com/document/d/1-eV4rB-mh4l8zYnU5q_ZzHcShTvQCIa_aRx46AB0Mrs/edit
>>
>>             On 11 May 2015 at 13:09, Dan Schutzer <cyberdan250@gmail.com
>> <mailto:cyberdan250@gmail.com>> wrote:
>>
>>             Merchant might say I don't accept American Express or I will
>> give a discount for cash for example.
>>
>>             On Mon, May 11, 2015 at 7:04 AM, <Joerg.Heuer@telekom.de
>> <mailto:Joerg.Heuer@telekom.de>> wrote:
>>
>>             Hi all,
>>
>>             Obviously, things can get pretty complex – not too
>> surprisingly I might say.
>>
>>             In a more abstract manner I would then state that the
>> ‘initiator’ of a payment transaction should also start to state the terms
>> i.e. the supported instruments.
>>
>>             A) In the simplest case this means that the merchant’s
>> payment system (on behalf of the payee) declares what the total asked is,
>> give a reference to the transaction itself (description, ID, ….) and the
>> supported schemes. Dan, what would that mean with respect to the demand
>> that merchants might want to decide? Could their statement be mandatory (‘I
>> only take VISA and that’s it’) and, thus, fulfill the requirement or would
>> the following be what you had in mind…
>>
>>             B) the payer states total, instrument(s) and a reference to
>> the actual transaction and if the payee is okay with it, just confirms and
>> does whatever the ‘reference’ implies (e.g. opening a turnstile or starting
>> a song on the jukebox)
>>
>>             Both cases could provide for another round of ‘negotiation’;
>> e.g. because the instruments or currencies couldn’t be matched or whatever.
>> They could use the ‘reference’ (which we would likely ask to be ‘unique’ in
>> some way) to continue communication, which might or might not imply other
>> data or even protocols.
>>
>>             However, one thing should be taken into account: With the
>> passing of a credential, the receiving side might already have received the
>> money – or at least gotten the right to withdraw the given amount from the
>> payer’s funding source. In the case of alternatives presented this seems
>> like a no-go for real value tokens (‘I give you three different tokens for
>> my three applicable cards and hope you only use one of them’). Also on the
>> payer’s side this might already create costs (creation of tokens might cost
>> something, amounts might be reserved or already be deducted). Thus, we
>> might be forced to run protocols with either one full-value token right
>> away, or a set of meta data about the instruments to be negotiated.
>>
>>
>>             My goal would be to make the basic communication as simple as
>> we can – and compatible to the current and the real world –  but leave
>> options open for additions. As I see it, we were able to complete most
>> transactions in one go and even with simple credit card-like data exchanges
>> for a start.
>>
>>             Cheers,
>>
>>             Jörg
>>
>>             *From:*Adrian Hope-Bailie [mailto:adrian@hopebailie.com
>> <mailto:adrian@hopebailie.com>]
>>             *Sent:* Freitag, 8. Mai 2015 22:25
>>             *To:* Dan Schutzer
>>             *Cc:* Heuer, Jörg; Joseph Potvin;
>> public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>
>>
>>
>>             *Subject:* Re: Linking Value Networks
>>
>>             I agree with everything you have there Jeorg.
>>
>>             I think the offer of sale should list payment options up
>> front (and different payment terms for each). This allows the payer to
>> immediately respond with their choice of instrument. The payee's response
>> could be some type of digitally signed quote confirming the terms which is
>> the signal to the payer to complete the payment and send proof.
>>
>>             This flow allows the payer to seek alternative means of
>> making the payment if they don't have an instrument that matches any of the
>> available mechanisms.
>>
>>             On 8 May 2015 at 20:06, Dan Schutzer <cyberdan250@gmail.com
>> <mailto:cyberdan250@gmail.com>> wrote:
>>
>>             There are situations where the payee or merchant gets to
>> decide what forms of payment they are willing to accept. Would be good to
>> allow for that option
>>
>>             On Fri, May 8, 2015 at 8:34 AM, <Joerg.Heuer@telekom.de
>> <mailto:Joerg.Heuer@telekom.de>> wrote:
>>
>>             Hello!
>>
>>             It’s good we are gathering confidence for automated solutions
>> being implementable. In the proximity world we already have to cope with
>> such situations and should probably try to do something similar in the
>> digital world in a first attempt:
>>
>>             ·First of all it’s a decision by the user. Just because I
>> happen to have a certain payment instrument doesn’t mean it’s open for use
>> in a given transaction at all. So we potentially have a subset of
>> pre-configured (by the user) instruments for a given context.
>>
>>             ·The actual pick needs to be made on the payers side as we
>> won’t try to send information about the content of a user’s ‘wallet’ to a
>> merchant. (I hope we agree on this…)
>>
>>             ·If automation just supports a user who is present, conflict
>> situations should be referred to him/ her to intervene and potentially
>> bring other options to the table – e.g. choosing an instrument which costs
>> him/her extra money..
>>
>>             ·If there is no user present, automation might require a
>> second round but we need to make sure the matching really ends after that
>> unless we want to create situations in which everybody waits for the other
>> to move…
>>
>>             ·For future scenarios we could consider that the payee
>> annotates the options offered in the first place to communicate rebates
>> etc. to promote specific options. (Which could in turn feed into decision
>> making in the payer’s side’s automation)
>>
>>             ·In how far automation with user present or user not present
>> can get more complex, I wouldn’t want to predict, but I’m sure it’s
>> important to always think such protocols in a ‘manned case’ as well as in
>> the ‘unmanned case’ for a number of reasons (simplicity, trust in
>> automation, backward-compatibility).
>>
>>             We have never implemented these more complex processes, but I
>> know pretty well we could do so pretty easily along a real human
>> interaction sequence. Adding automated negotiation e.g. could be an
>> interesting option for the future but will be much harder to make people
>> trust in. So let’s start simple, I’d say.
>>
>>             Cheers,
>>
>>             Jörg
>>
>>             *From:*Joseph Potvin [mailto:jpotvin@opman.ca <mailto:
>> jpotvin@opman.ca>]
>>             *Sent:* Freitag, 8. Mai 2015 04:35
>>             *To:* Dan Schutzer
>>             *Cc:* Adrian Hope-Bailie; Web Payments IG
>>             *Subject:* Re: Linking Value Networks
>>
>>             RE: "requires more than just a technical solution, it
>> requires some business innovation"
>>
>>
>>             The answer is:
>>
>>             OASIS UBL v2.1 Universal Business Language
>>             https://www.oasis-open.org/committees/ubl/
>>             http://ubl.xml.org/wiki/ubl-resources
>>             ...which is currently advancing as ISO 19845
>>             http://www.iso.org/iso/catalogue_detail.htm?csnumber=66370
>>
>>             See also:
>>
>> http://docs.oasis-open.org/ubl/UBL-Governance/v1.0/cn01/UBL-Governance-v1.0-cn01.html
>>
>>             ...and for a couple of examples regarding its significance:
>>
>> http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014D0771&from=EN
>>
>> http://eeiplatform.com/13559/towards-single-standard-e-invoicing-eu-public-procurement-6-years-wow/
>>
>>             Joseph Potvin
>>             Operations Manager | Gestionnaire des opérations
>>             The Opman Company | La compagnie Opman
>>             jpotvin@opman.ca <mailto:jpotvin@opman.ca>
>>             Mobile: 819-593-5983 <tel:819-593-5983>
>>
>>             On Thu, May 7, 2015 at 9:45 AM, Dan Schutzer <
>> cyberdan250@gmail.com <mailto:cyberdan250@gmail.com>> wrote:
>>
>>             You make a good point - but to address this concern it
>> requires more than just a technical solution, it requires some business
>> innovation, but it can be addressed much in the same way that Square and
>> PayPal can helped in areas where the payee is too small and not credit
>> worthy enough to directly accept credit card payments.
>>
>>             On Thu, May 7, 2015 at 9:33 AM, Adrian Hope-Bailie <
>> adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote:
>>
>>             In working on the manifesto and the architecture document it
>> occurred to me that we (or maybe it's just me) may be missing an essential
>> feature in the payment agent model.
>>
>>             If our payment agents are expected to talk to one another to
>> negotiate the terms of a payment, including the choice of payment scheme,
>> then what do we do when there is no common scheme between the participants?
>>
>>             Does the payment agent give up and say: "Sorry Alice, you
>> can't pay Bob he only accepts Visa, Bitcoin and ACH and you can only pay
>> via MasterCard and XRP, transaction aborted"?
>>
>>             If so then it seems we aren't solving anything. Our vision
>> for inter-connected value networks falls flat if our payment agents can
>> only facilitate a payment within existing closed networks.
>>
>>             Would I be correct in saying we need to consider that in many
>> scenarios there will be one or more intermediaries that "bridge" the two
>> networks by being plugged into both? How do we fit these
>> brokers/intermediaries into our architecture?
>>
>>             I think they are also payment agents of some sort but who do
>> they interface with? The sender, receiver, both? And, how does the payment
>> flow between Alice and Bob play out when this intermediary is required? At
>> what point do their agents say, "Oh dear, we don't have a common payment
>> scheme we can use, let's call Fred to act as a broker between your
>> MasterCard and my Visa accounts".
>>
>>             I'd like to discuss this on the call today as I think we need
>> to figure it out and put it in the document.
>>
>>             Adrian
>>
>>
>>
>>
>>             --
>>
>>
>>
>>
>
Received on Monday, 11 May 2015 13:59:30 UTC

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