Re: Linking Value Networks

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