Re: [payment arch] Negotiation of payment terms

I don't know what you mean by "the aggregation takes place via credentials".
Can you elaborate?

On 12 May 2015 at 18:49, <Joerg.Heuer@telekom.de> wrote:

> Hello!
>
>
>
> Actually, I reviewed the architecture document as I promised to introduce
> credentials back into the picture. As it shows, the current setup doesn’t
> really support this because the agents have access to the funds directly.
> Looking at the invoice-based initiation below, I come to the conclusion
> that credentials should play a crucial role in the architecture instead of
> a functional relationship as we have it now.
>
>
>
> My main problem in the document was that we can’t differentiate between
> the individual funding source and the aggregation role of the agent. If the
> aggregation takes place via credentials, we’d get a good grip on the topics
> in real world payment scenarios. Basically the invoice constitutes a
> credential of some sort and it is responded to by either another (set of)
> credential(s) or meta data in a more complex communication. I think, this
> is a lot of benefit which we could create if we dare to rethink ‘agents’
> again before we get stalled.
>
>
>
> Jörg
>
>
>
> *[…]*
>
>
> A quick note:
>
> If we design this such that the offer is digitally-signed and includes all
> necessary terms agreeable to the payee, then no interaction is necessary
> with the store's payment agent to initiate and process the payment.
> Instead, the payer's browser forwards the offer to the payer's payment
> agent, which will then simply communicate with the appropriate payment
> processor to perform the payment/hold and receive a digitally-signed
> receipt. Then the payer's payment agent passes the receipt to the store's
> payment agent, which checks the signature and the transaction will be
> considered complete (or, in the case of a hold, funds can then be captured).
>
>
>
>
> 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.
>
>
> If we do the above, we could do: startTransaction(Offer offer) or
> startTransaction(URL offer).
>
>
>
>
> 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> 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> 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> 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]
> *Sent:* Montag, 11. Mai 2015 13:25
>
>
> *To:* Dan Schutzer
> *Cc:* Heuer, Jörg; Joseph Potvin; 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> 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> 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]
> *Sent:* Freitag, 8. Mai 2015 22:25
> *To:* Dan Schutzer
> *Cc:* Heuer, Jörg; Joseph Potvin; 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> 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> 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]
> *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
> Mobile: 819-593-5983
>
>
>
>
>
> On Thu, May 7, 2015 at 9:45 AM, Dan Schutzer <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>
> 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
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Dave Longley
>
> CTO
>
> Digital Bazaar, Inc.
>
> http://digitalbazaar.com
>
>