Re: VOTE: Revised Payment Initiation / Wallet Web Payments Workshop Use Cases

Adrian,

RE:  "The way this will be expressed and calculated requires some
pretty serious thought"...

:-)  Yup. I'm currently up to my knees it, writing my doctoral
disseration at UQuebec entitled "Free/Libre/Open World Market Payment:
A Model of Potential Arrangements and Emergent Effects". We'll be
modeling this with MASON Lagom regiO
http://www.alde.es/encuentros/anteriores/xveea/trabajos/p/pdf/96.pdf

RE:
Version 1 Scope: Explicit data provided between the payer and payee
Version 2+ Scope: Introduce calculated data and rules for calculation.

That seems like a coherent way to organize the process, but I wonder
if the structure you describe is what you fully intend? The WM Reuters
Spot Exchange Rate is a calculated item. Do you mean that Version 1
should not include any reference to an exchange rate?

RE: Your illustration of Version 2 as:
Channel:PayPal
- Prices [EUR 30, CND 48.03]
- Supported currency conversion indexes:
[http://paypal.com/indices/EURIndex or http://anotherplace.com/EUR]

There are two contexts in which to handle value-in-exchange
benchmarking: via currency-conversion, and via contract terms.

By handling it in currency conversion as you illustrate, this limits
the issue to multi-currency transactions, and places it legally under
capital controls law.

Handling it as algorithmic pricing in contracts, it also includes
time-deferred payment use cases (eg payment installments)  and keeps
it legally under contract law. It seems to me this would be both more
useful to business, and less complicated legally.


-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983






On Wed, Jul 30, 2014 at 8:53 AM, Adrian Hope-Bailie
<adrian@hopebailie.com> wrote:
> Joseph,
>
> I unfortunately can't make the call today but here is my take on this.
> Version 1 of the spec should cater for explicit data provided between the
> payer and payee and in later versions introduce calculated data and rules
> for calculation.
>
> Version 1
> As the payer I get presented with a number of payment options from the payee
> (in the form of a machine readable document - probably JSON-LD).
> I select the option I prefer and make the payment.
> If the payee offers payment in different currencies or requires different
> amounts to be paid based on the channel then they must all be listed.
> i.e. In your example my options may be:
> Channel: PayPal
>  - Prices [EUR 30, CND 48.03]
>
> As the payer I know I am providing a payment instrument that will be charged
> in CDN so I know that I will only find out what the conversion rate is when
> the transaction completes if I choose the EUR price.
> This at least gives us what is available today.
>
> Version 2
> Introduce calculation rules.
> Each payment channel now offers payment options including rules about how
> conversions will be done.
> Channels can provide multiple sources of conversion rates and the payer
> picks the one they want used.
> Ultimately this may evolve into smart contracts that could specify a date to
> make the conversion etc etc
>
> My options may now be:
> Channel:PayPal
> - Prices [EUR 30, CND 48.03]
> - Supported currency conversion indexes: [http://paypal.com/indices/EURIndex
> or http://anotherplace.com/EUR]
>
> This is all very simplified but I hope it illustrates the theory.
> The way this will be expressed and calculated requires some pretty serious
> thought and a whole swathe of new use cases.
> Hence, I'm inclined to put it out to a later version.
>
> Adrian
>
>
>
> On 30 July 2014 14:12, Joseph Potvin <jpotvin@opman.ca> wrote:
>>
>> Manu, Thanks, I'll be on today's call. In summary, here are five
>> points I request that the group consider:
>>
>> 1. To its credit, Paypal already implements this use case. For the
>> screenshots of the Paypal process that I presented in Paris, please
>> see: http://www.w3.org/2013/10/payments/slides/session4_potvin.pdf   I
>> suggest that a W3C spec for this use case can be both simpler and
>> fully generic (i.e. not limited to just the two choices that the
>> payment intermediary determines to present).
>>
>> 2. The global market is moving in the direction I'm describing. For
>> one example, here's an announcement just this week about a bitcoin
>> derivative anchored to a primary commodity benchmark: http://uro.io/
>> [1]
>>
>> 3. There exists no "true exchange rate". It's just an algorithm
>> maintained by a private self-interested consortium, and is subject to
>> manipulation:
>>
>> http://www.theguardian.com/business/2014/jul/21/foreign-exchange-trading-criminal-investigation-serious-fraud-office
>>
>> 4. A decision to defer this use case is a de facto decision to have
>> V1.0 of the W3C spec accommodate payments intermediaries restricting
>> payees and payers to a benchmark that is known to be manipulated, and
>> also to accommodate arbitrary skimming from every transaction. In a
>> market, choice of benchmark is the prerogative of the parties to the
>> contract to determine, not the payments intermediaries. Of course
>> payments intermediaries do have every right to be fully compensated
>> for their services, but a W3C standard ought not to conflate the
>> intermediary's fee-for-service (a micro-economic concept) with the
>> monetary value-in-exchange benchmark (a macro-economic concept).
>> Defaulting those two together subverts the objective of transparency
>> and fairness in web payments.
>>
>> 5. If there has been industry push-back against this use-case, it may
>> have been behind closed doors and not in the open discussion fora. As
>> far as I can tell we've seen no reasons presented against it, but this
>> might be because this level of transparency is more controversial than
>> might be comfortable in open discussion. So, IF the concern is that
>> including this use case would de-rail the entire schedule for v1.0 of
>> the spec, I propose that deferral be explicitly attached to a process
>> towards open deliberation and resolution, linked to a schedule.
>>
>> - - -
>>
>> [1] Background: I've not been involved in http://uro.io/ but I am busy
>> helping various teams to operationalize fundamentally different
>> value-in-exchange benchmarks, including commodity-based ones. If
>> you're interested in the commodity-based concept generally, here's a
>> short overview that I co-authored back in 2009:
>>
>> http://www.theglobeandmail.com/globe-investor/investment-ideas/commodities-as-a-global-currency/article1346127/
>>   Since 2009 in discussions with people in banking and monetary
>> systems-design, we've realized the practicality of de-coupling
>> unit-of-account from value-in-exchange benchmark. If you've ever been
>> in a country that had a so-called "black market" offering exchange
>> rates different than the banks, that's what de-coupling looks like.
>> I'll be happy to elaborate on legally sound vs legally problematic
>> ways to approach this.  My interventions with the W3C CG on this topic
>> benefit from discussions in other venues about how to approach this
>> use case well-within bounds existing statute and case law.
>>
>>
>> --
>> Joseph Potvin
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>> On Tue, Jul 29, 2014 at 11:19 PM, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>> > On 07/22/2014 08:50 AM, Joseph Potvin wrote:
>> >> RE: Use Case: A merchant advertises different details, such as price,
>> >> for an offer of sale based on potential payment processor choice.
>> >>
>> >> I wish to ask if the "value-in-exchange benchmarking" issue I
>> >> presented about in Paris is intended to be incorporated in this use
>> >> case, or is benchmarking elsewhere and I haven't noticed?
>> >
>> > The value-in-exchange benchmarking issue was deemed to be out of scope
>> > for the first iteration (and is something that could be implemented by
>> > payment processors w/o it being mandated via a specification). We don't
>> > know if it's a good technical design to mandate it in the specification
>> > because we can't really police it via technology. It's a policy
>> > decision, not a technological one.
>> >
>> > I've added the use case you mentioned back into the list for further
>> > discussion:
>> >
>> >> Use Case: Payee and payers negotiate secure price in an open market.
>> >>  They are free to choose all three essential attributes of the
>> >> numeric quantity expressing a price (e.g. 10.99), namely: a
>> >> unit-of-account (e.g. $ £ € ¥ etc.); a medium-of-exchange (e.g.
>> >> debit card, credit card, web payment etc.); and, a value-in-exchange
>> >> benchmark (e.g. WM Reuters Spot Exchange; Purchasing Power Parity;
>> >> Commodity Index; etc.)
>> >
>> > It's already agreed that we will support listing the unit-of-account,
>> > and medium-of-exchange. I guess we could also support value-in-exchange
>> > by providing an index URL along w/ the price of the good... so the way
>> > one /could/ list items for sale is:
>> >
>> > "payee": [{
>> >     "id": "http://example.com/articles/1#offer-payee",
>> >     "type": "Payee",
>> >     "currency": "USD",
>> > *** "priceBenchmark": "https://reduters.com/spot-exchange-rates",
>> >     "destination":
>> > "https://payswarm.example.com/i/bob/accounts/primary",
>> >     "rate": "0.05",
>> >     "rateType": "FlatAmount",
>> >     "comment": "Payment for PaySwarm in Practice by Digital Bazaar."
>> >   }],
>> >
>> > We'll discuss in more detail on tomorrows call.
>> >
>> > Who sets the value-in-exchange benchmark? The payer or the payee?
>> >
>> > -- manu
>> >
>> > --
>> > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> > Founder/CEO - Digital Bazaar, Inc.
>> > blog: The Marathonic Dawn of Web Payments
>> > http://manu.sporny.org/2014/dawn-of-web-payments/
>> >
>>
>

Received on Wednesday, 30 July 2014 13:52:23 UTC