Re: Linking Value Networks

I think the flow should be:

Payee sends Offer (including various available terms)
Payer sends Acceptance of offer (including choice of terms)
Payee sends Signed quote (including finalised terms)

Then depending on the terms (payment before or after delivery)
Payer sends Signed Proof of payment
Payee sends Signed Receipt
Payer claims goods/service
OR
Payer sends Signed Acceptance of Quote
Payee provides access to goods/service
Payer consumes good/service
Payee sends Signed Invoice
Payer sends Signed Proof of Payment

On 11 May 2015 at 13:27, <Joerg.Heuer@telekom.de> wrote:

> So, in a payee-initiated transaction he would say so in the very
> beginning, stating he only supports A, C, D – leaving out ‘D’ because he
> doesn’t do. No problem here – and nothing that would force us to deny the
> payer a ‘last decision’.
>
>
>
> The discount should be communicated up-front as well, I think. Semantic
> were: ‘Here is the total if you pay with an of the following instruments;
> if you decide to pay cash or allow us direct debit the total will be
> reduced to…’ In the case the payer decides to go for the discount, another
> statement of total and instruments might be made, limited to the direct
> debit mechanism.’
>
>
>
> What I find tricky about this is: if we went for a multi-phased
> negotiation, it might become possible to get a better price for the same
> goods because you held back the more attractive option long enough. Might
> sound okay, but may lead to a built-in denial-of-service routine… ;-)
>
>
>
> Cheers,
>
>                 Jörg
>
>
>
> *From:* Dan Schutzer [mailto:cyberdan250@gmail.com]
> *Sent:* Montag, 11. Mai 2015 13:09
> *To:* Heuer, Jörg
> *Cc:* Adrian Hope-Bailie; Joseph Potvin; public-webpayments-ig@w3.org;
> Dan Schutzer
>
> *Subject:* 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
>
>
>
>
>
>
> --
>
>
>
>
>
>
>