Re: [payment arch] Negotiation of payment terms

Hi guys,

Can we unpack a few concepts here to avoid any confusion.

Firstly, credentials. I define a credential as a piece of information about
an entity that can be tested to some extent by the consumer of the
information. In other words I may have a credential that says I am older
than 21. It is a piece of data about me that says nothing about who I am
but just says something about me. If that information is stored in the form
of some signed data and the signature is from someone that realistically is
able to ensure I  really am over 21 then the consumer of the credential has
a high likelihood of trusting that I am indeed over 21. I think a review of
the Credentials CG's proposed charter is worth reviewing:
https://docs.google.com/document/d/1xfdzFahQpaQKGL4aOvePlIdsJO6Q5OJkPgSIxtUx9Vc/
(We'll be seeing this at the face to face so read it now to prepare!)

Second, identity. This is a very loaded word. It SHOULD be interpreted to
mean some collection of credentials that are known to all belong to the
same entity. I.e. I am over 21 and a citizen of South Africa. Again, you
know nothing about who I am but have shared my identity with you. If you
want to know who I am I need to share a specific credential with you that
proves this in the context you are asking. i.e. Do you want to know who I
am in the context of a loyalty program? Then here is a credential that
tells you my loyalty program number. Do you want to know who I am in the
context of being a legal entity in South Africa? Then here is a credential
that gives you my national id number or passport number.

With these two terms defined as such I am still not sure why there is any
concern about the payment agent architecture? I would think it is essential
that payment agents have the ability to send and receive credentials as
part of any payment. This could be to establish some identity or for
another purpose but storage, signing, exchange etc of credentials will
naturally be part of the payment agent's functions.

In answer to your statement Joerg I'd say that the payment agent is the
central architectural concept and credentials will be a key part of the
messaging.


On 13 May 2015 at 20:32, David Jackson <david.dj.jackson@oracle.com> wrote:

> Several of the “drags” on providing of identity to the merchant are – loss
> of information to hackers; misuse by merchant; contact after the attempted
> sale even if the sale does not conclude; feeling of being invasive without
> merchant providing value prior to the customer (feeling by customer of
> providing data without “knowing” or yet “trusting” the merchant) – and the
> inevitable multiple (and sometimes disgracefully painful – near harassment
> – after the sale.
>
>
>
> In my turns through eCommerce, there are some of the complaints I’ve heard
> and why some customers will resort to cash or avoiding certain merchants
> (several come to mind which personally are known to be horrific at
> harassment of continuous contact).  So one thing just might be – setting up
> a relationship PRIOR to purchase and then the consumer – once comfortable –
> will more easily be known to and trusting of the merchant.  This aspect is
> beyond the purchase process but is rarely considered by the retailers in
> the process.  Most consumers will provided nearly anything asked, but there
> is a ceiling to this blind trust.
>
>
>
> One possible idea might be to identify that the merchant already knows the
> customer and take it down the mutual trust path being thought here.  The
> question is how to handle the “looker” online into the possibility of a
> merchant relationship.  Cart abandonment goes WAY up when the merchant
> “mugs” the buyer just to look or put something in a cart.  That might also
> by the case for the first sale and the customer experience after the sale.
>
>
>
> While this isn’t really part of the “payment” – I think we need to be
> thinking of how the merchants of various types will want to handle the
> relationship and how much “needs” to be known for the sale until trust is
> established.  This differs for businesses which generally only do one sale
> to the client (or very few).
>
>
>
> --
> [image: Oracle] <http://www.oracle.com/>
> David Jackson | Senior Director Financial Services
> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
> <+16144656654>
> Oracle Industry Solutions Group
> New York City | Columbus
>
> [image: Green Oracle] <http://www.oracle.com/commitment>
>
> Oracle is committed to developing practices and products that help protect
> the environment
>
>
>
>
>
> *From:* Dan Schutzer [mailto:cyberdan250@gmail.com]
> *Sent:* Wednesday, May 13, 2015 1:58 PM
> *To:* Joerg.Heuer@telekom.de
> *Cc:* Nick.Telford-Reed@worldpay.com; Dave Longley;
> public-webpayments-ig@w3.org; Adrian Hope-Bailie
>
> *Subject:* Re: [payment arch] Negotiation of payment terms
>
>
>
> I agree - many people would just as soon not be identified by the
> merchant, thus the continuing popularity of cash and prepaid
>
>
>
> On Wed, May 13, 2015 at 1:52 PM, <Joerg.Heuer@telekom.de> wrote:
>
> I just wanted to make sure whether there is reason to assume that mutually
> identified parties are the goal. But what I read here is exactly why I
> regard identity to be of utmost importance here. However, the processes to
> get proper proofs, and to build up trust so that e.g. even brick-and-mortar
> shop customers would want to be identifiable to the merchant, are manifold
> and  potentially entirely different according to region and vertically. So
> we can’t require or even assume identity being established, but we can make
> sure that means are there to provide proofs upon enrolment or alongside
> payment. There is virtually no limit to how much could be going on between
> customer, shop and financial institute, but there is very little that is
> mandatorily required.
>
>
>
> Cheers,
>
>                 Jörg
>
>
>
> *From:* Telford-Reed, Nick [mailto:Nick.Telford-Reed@worldpay.com]
> *Sent:* Mittwoch, 13. Mai 2015 19:11
>
>
> *To:* Heuer, Jörg; adrian@hopebailie.com
> *Cc:* dlongley@digitalbazaar.com; public-webpayments-ig@w3.org
> *Subject:* RE: [payment arch] Negotiation of payment terms
>
>
>
> Jörg
>
> What I meant was that all financial transactions occur in the context of
> some identification process for both parties. The level of assurance and
> nature of those credentials varies enormously. So yes, in a sense it’s a
> policy decision on the part of both parties.
>
> I guess what was driving at is that the establishing of a trust context
> for payments which is itself derived from identity credentials is a factor
> in the negotiation of the payment instrument (and possibly price). A
> mundane but obvious example today is that shoppers might be more likely to
> use a credit card for a transaction where they are worried about the
> reliability of a particular merchant (because they know they get a good
> deal of protection and ultimately the ability to reverse the transaction if
> the goods/services are not delivered), and that choice may be influenced by
> what the shopper knows or thinks they know about the
> identity/brand/capability of the merchant.
>
>
>
> Alternatively, a merchant might accept a card payment without CVV or AVS
> or 3DS from a shopper that they were able to identify through other means
> (like user name and password). Or they might offer a line of credit to an
> established customer that would not offer to a new customer about whom they
> knew very little.
>
>
>
> Even in a crypto-currency situation this might apply. For example, a
> merchant might accept a bitcoin transaction from a well-known and
> identified existing customer with one or even no confirmations on the block
> chain before providing the goods/service. But the same merchant might
> choose to require 6 confirmations if they nothing more than the bitcoin
> address from which the transaction originated.
>
>
>
> In other words – what each party knows about the counter-party affects the
> payment negotiation. I don’t necessarily mean a static identity of say
> government-backed attributes bound to a particular identity instrument. I
> mean a broader dynamic identity that might include behavioural or historic
> factors alongside static attributes. This happens today so our architecture
> needs to reflect this.
>
>
>
>
>
> Nick
>
>
>
> --
>
> Nick Telford-Reed
>
> e: nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069
>
>
>
> *From:* Joerg.Heuer@telekom.de [mailto:Joerg.Heuer@telekom.de
> <Joerg.Heuer@telekom.de>]
> *Sent:* 13 May 2015 16:24
> *To:* Telford-Reed, Nick; adrian@hopebailie.com
> *Cc:* dlongley@digitalbazaar.com; public-webpayments-ig@w3.org
> *Subject:* RE: [payment arch] Negotiation of payment terms
>
>
>
> Hi Nick,
>
>
>
> ‘Mediated through the identities’ isn’t really clear to me. Credentials
> are technical representations of payment services, authentication elements
> and identities (whatever you call an ‘identity’). As we are supposed to
> bring up a universal architecture which supports privacy and user-control
> inherently I’d think that credentials are our main tools to accomplish this.
>
>
>
> They can be governmental identity credentials which a financial
> institution accepts to grant access to your account or they can be
> anonymous vouchers, pre-paid cards or –  more innovative things like
> crypto-currencies – which just require a certain degree of protection but
> no person’s identity to work. Taking this a basis basis, it is then a
> matter of policies whether you’d need more in a certain given jurisdiction
> to be allowed to perform monetary transactions…
>
>
>
> I wasn’t sure whether your statement wouldn’t imply the contrary, that
> financial transactions always require fully identified parties – which I’d
> find more than a bit scary, actually. ;-)
>
>
>
> Cheers,
>
>                 Jörg
>
>
>
> *From:* Telford-Reed, Nick [mailto:Nick.Telford-Reed@worldpay.com
> <Nick.Telford-Reed@worldpay.com>]
> *Sent:* Mittwoch, 13. Mai 2015 15:01
> *To:* Heuer, Jörg; adrian@hopebailie.com
> *Cc:* dlongley@digitalbazaar.com; public-webpayments-ig@w3.org
> *Subject:* RE: [payment arch] Negotiation of payment terms
>
>
>
> I think exchange of identity credentials is a precursor to any negotiation
> of payment instrument. All payment negotiations are mediated through the
> identities of the parties. It’s just that today, the payment instrument
> also often stands for the identity (especially in the world of cards)
>
>
>
>
>
>
>
> --
>
> Nick Telford-Reed
>
> e: nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069
>
>
>
> *From:* Joerg.Heuer@telekom.de [mailto:Joerg.Heuer@telekom.de
> <Joerg.Heuer@telekom.de>]
> *Sent:* 13 May 2015 10:37
> *To:* adrian@hopebailie.com
> *Cc:* dlongley@digitalbazaar.com; public-webpayments-ig@w3.org
> *Subject:* RE: [payment arch] Negotiation of payment terms
>
>
>
> Hi Adrian,
>
>
>
> I’d say that we’d come much closer to our goals if we made credentials the
> central concept instead of the symmetrical agent setup which I haven’t seen
> any benefit for yet. But I think I found a way to adapt:
>
>
>
> We will need to state that credentials MAY be used through either
> interface of an agent.
>
>
>
> Any comments on this approach?
>
>
>
> Cheers,
>
>                 Jörg
>
>
>
> P.S: One more response below
>
>
>
> *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com
> <adrian@hopebailie.com>]
> *Sent:* Dienstag, 12. Mai 2015 22:06
> *To:* Heuer, Jörg
> *Cc:* Dave Longley; Web Payments IG
> *Subject:* Re: [payment arch] Negotiation of payment terms
>
>
>
> I don't think the proposed architecture prevents that, in fact I'd say
> that is necessary for many implementation scenarios but I don't think it is
> essential.
>
> What is stopping a payment provider (like PayPal or Venmo or Stripe or
> ....) including a payment agent in their app and building direct account
> access into this?
>
> They would have to authenticate for security reasons – why not be
> consistent and require this to be done with credentials?
>
> At this level of the design I think we are too abstract to say that
> credentials MUST be in any place or that we will always need credentials
> for every use case.
>
> Is it possible that as an entity I have multiple payment agents and one of
> these aggregates the others?
>
>
>
> On 12 May 2015 at 19:43, <Joerg.Heuer@telekom.de> wrote:
>
> If the agent holds credentials good for all my different funding sources
> and additional services, Id see this as an aggregation on a level the user
> can understand and control (which would also make clear where the user
> interaction is orchestrated). Tokenization in payments and authentication
> tokens like OAuth among others are well-suited to implement relevant
> solutions on this basis.
>
>
>
>
>
> *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
> *Sent:* Dienstag, 12. Mai 2015 19:10
> *To:* Heuer, Jörg
> *Cc:* Dave Longley; Web Payments IG
> *Subject:* 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
>
>
>
>
>
>
>
>
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
>
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>
>
>
>
>
>
>
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
>
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>
>
>
>
>
>