RE: Linking Value Networks

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<mailto:jpotvin@opman.ca>
Mobile: 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




--