Support multiple simultaneous currencies and price algorithms
Opened this issue · 26 comments
When a vendor lists their product for sale, they should be able to list multiple currencies that are accepted for the sale. They should also be able to specify multiple pricing algorithms so that prices track vendor-chosen indexes, such as the current trading price for gold, oil, or a basket of commodities.
More background can be found here:
http://lists.w3.org/Archives/Public/public-webpayments/2013Oct/0108.html
When a vendor lists their product for sale, they should be able to list multiple currencies that are accepted for the sale.
This can currently be done with PaySwarm.
They should also be able to specify multiple pricing algorithms so that prices track vendor-chosen indexes, such as the current trading price for gold, oil, or a basket of commodities.
The way this is handled in PaySwarm at the moment is to reproduce (and sign) new listings on daily (or hourly or whatever) basis. Any price indexes, etc. are handled out-of-band; any changes to the prices can just be incorporated into the new payee rates in the next listing that gets published. We could require PaySwarm Authorities/Payment Processors to understand price indexes and require that a particular protocol be spoken so that they can obtain the right rates at the time of sale, but this might be unnecessary complexity. Currently, the responsibility to update listing prices is the vendor's responsibility -- and they can use whatever standard or proprietary method they prefer.
RE: "We could require PaySwarm Authorities/Payment Processors to understand price indexes and require that a particular protocol be spoken so that they can [interpret] the right [price] at the time of sale"
Not only at time of sale, but also in the Listing and the PayeeRule, I think. The "multi-currency" price would be listed in a similar context as multilingual content -- the variants are supposed to mean the same thing, but are just expressed differently. Choosing a multi-currency price indexing service would be equivalent to choosing a language translation service -- you'll get different results depending who's service you choose. But that choice of interpreter belongs to the vendor. Once that choice is made by the vendor, then the purchaser gets to choose, from amongst those offered, which price/currency to actually pay in. That pair of choices, first the set acceptable to the vendor, then a particular one by the purchaser would (I think) establish the PriceSpecification in the transaction http://schema.org/PriceSpecification
Below I attempt an admittedly naïve edit of the AssetProvider and Listing examples from /vocabs/payswarm.
I am wondering if the AssetProvider might declare the currencies they accept across all their business AND/OR at the level of any Listing (which they can handle by tagging their listings if there are geographical or product-line differences).
RE: Example at https://payswarm.com/vocabs/payswarm#assetProvider
{
"@subject": "http://example.com/articles/1#listing",
"@type": ["gr:Offering", "ps:Listing"],
"com:payee":
[
{
"@subject": "http://example.com/articles/1#listing-payee",
"@type": "com:Payee",
"com:currency": "USD", "EUR", "BTC" <<< THIS VENDOR WOULD ACCEPT PAYMENT IN ANY OF THESE
"com:destination": "https://payswarm.example.com/i/bob/accounts/primary",
"com:pricealgorithm": "WPI", <<< GENERIC LANGUAGE TO DISTINGUISH FROM THE PARTICULAR CASE OF "EXCHANGE RATE"
"com:rateType": "com:Algorithmic", <<< EVEN OFFICIAL EXCHANGE RATES ARE JUST ANOTHER VARIABLE PRICE ALGORITHM
"rdfs:comment": "Payment for PaySwarm in Practice by Digital Bazaar."
}
Similarly...
RE: Example at https://payswarm.com/vocabs/payswarm#listing
{
"@subject": "http://payswarm.example.com/contracts/28394729347",
"@type": ["ps:Transaction", "ps:Contract"],
"com:amount": "0.05", <<< THIS REQUIRES A DATE/TIME, BECAUSE AFTER THE VENDOR SETS THEIR STARTING PRICE IN THE CURRENCY OF THEIR CHOICE. GOING FORWARD, THE EXPRESSED PRICE IN THIS CURRENCY WILL VARY ACCORDING TO THE CHOSEN INDEX
"com:currency": "USD", <<< THIS CAN BE THE CURRENCY THAT THE VENDOR USES FOR ENTERING A VALUE, BUT FROM THAT POINT (UNTIL CHANGED AGAIN BY THE VENDOR, THE PRICES WOULD BE POSTED IN ALL THE CURRENCIES THAT THE VENDOR ACCEPTS, JUST AS ANY DESCRIPTION OF THE GOODS OR SERVICES WOULD BE IN THE LANGUAGES THAT THE VENDOR WANTS TO USE.
"com:date": "2011-03-02T03:00:53Z",
...
"ps:listing":
{
"@subject": "http://example.com/articles/1#listing",
"@type": ["gr:Offering", "ps:Listing"],
"com:payee":
[
{
"@subject": "http://example.com/articles/1#listing-payee",
"@type": "com:Payee",
"com:currency": "USD", "EUR", "BTC" <<< THE VENDOR WOULD ACCEPT PAYMENT IN ANY OF THESE
"com:destination": "https://payswarm.example.com/i/bob/accounts/primary",
"com:pricealgorithm": "WPI", <<< GENERIC LANGUAGE TO DISTINGUISH FROM THE PARTICULAR CASE OF "EXCHANGE RATE"
"com:rateType": "com:Algorithmic", <<< EVEN OFFICIAL EXCHANGE RATES ARE JUST ANOTHER VARIABLE PRICE ALGORITHM
"rdfs:comment": "Payment for PaySwarm in Practice by Digital Bazaar."
}
I also think this would be addressed under PayeeRule https://payswarm.com/vocabs/commerce#payeerule
There are presently two options: "either flat rates or exclusive percentages". I suggest to generalize that to "pricealgorithm", so that "flat rate" us just a special case. I see the note on that page: "Issue: Why would anyone ever need this? We need to explain."
Is the above making sense? I presume I've got some things a little confused, but hope that the intent is clear enough.
But that choice of interpreter belongs to the vendor. Once that choice is made by the vendor, then the purchaser gets to choose, from amongst those offered, which price/currency to actually pay in.
With that in mind, it might be better to have the vendor use software to simply generate multiple listing options that they can offer to the consumer rather than building everything into the core protocol. You can eliminate the complexity and give vendors more leeway if you let them do the translation (however they want to). Of course, the trade off is that they have to run the software to do the translating (or a client that hits a service to do it for them), but I think that's a much simpler way to go.
For instance, a vendor could use an application (or service) that takes whatever inputs are necessary for the currencies they accept, and it would output a set of listings for them to put on their site. Then a consumer simply browses through the available listings (or searches), based on their own criteria, selecting the listing they prefer. This makes it easier for the consumer to understand the price of the asset, with fewer real time calls out to "resolve" prices for them. The vendor could use this service daily to get up-to-date listings for their consumers to choose from. This approach keeps the messy details out of the core protocol and allows vendors to use whatever price indexes and applications, etc. they want to. This can also clear the way for more innovation.
Dave, the architecture I'm suggesting does keep the indices per se outside
the W3C protocol, pretty much as I think you suggest. I'd have posted this
rough business-UML diagram a few days ago, but I have some known edits to
do. Anyways, here it is for the time being. The "global price index
services" would exist in an external open competitive market.
The only thing that the standard would need to do is handle a vendor
selecting more than one currency, and if more than one, then also a price
index. The common index to choose (today) is the bank's official exchange
rate index, but there can be many reasons to choose other indices more
relevant to a given vendor's market and preferences. Once an index is
chosen, the set of available "global price index services" that confirm to
the required protocol would be available to for the vendor to choose from.
The various implementation software suppliers can provide grouping and
filtering once there are many indices to choose from -- so also that would
stay outside the protocol.
Does this address your concern fully? Or am I neglecting something?
Joseph Potvin
On Mon, Nov 4, 2013 at 4:36 PM, Dave Longley notifications@github.comwrote:
But that choice of interpreter belongs to the vendor. Once that choice is
made by the vendor, then the purchaser gets to choose, from amongst those
offered, which price/currency to actually pay in.With that in mind, it might be better to have the vendor use software to
simply generate multiple listing options that they can offer to the
consumer rather than building everything into the core protocol. You can
eliminate the complexity and give vendors more leeway if you let them do
the translation (however they want to). Of course, the trade off is that
they have to run the software to do the translating (or a client that hits
a service to do it for them), but I think that's a much simpler way to go.For instance, a vendor could use an application (or service) that takes
whatever inputs are necessary for the currencies they accept, and it would
output a set of listings for them to put on their site. Then a consumer
simply browses through the available listings (or searches), based on their
own criteria, selecting the listing they prefer. This makes it easier for
the consumer to understand the price of the asset, with fewer real time
calls out to "resolve" prices for them. The vendor could use this service
daily to get up-to-date listings for their consumers to choose from. This
approach keeps the messy details out of the core protocol and allows
vendors to use whatever price indexes and applications, etc. they want to.
This can also clear the way for more innovation.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-27724951
.
The only thing that the standard would need to do is handle a vendor
selecting more than one currency, and if more than one, then also a price
index.
The alternative I'm suggesting would be to just generate separate listings for each currency that is accepted -- fully keeping any sort of indexes entirely out of the core e-commerce protocol. The accounts used to perform the transaction would preserve the currency (no exchanging necessary), moving it from a PaySwarm Financial Account of currency X to another one, also of currency X. Exchanging currencies could be done (if desired) at the local PaySwarm Authority/Payment Processor or through a "PaySwarm Currency Mint" that may simply leverage external exchanges. This approach may also include using Ripple's currency, XRP, for cross-currency purchases.
My main point is that we should try to layer these features as much as we can to avoid complexity in the core protocol. If we don't have to handle currency exchange there (by pushing it to another layer or to another technology like Ripple), it may be best to avoid doing so. That approach allows currency exchange to happen when desired rather than at the point of sale; if the desired time is at the point of sale, then using Ripple may simplify PaySwarm implementations and reduce the number of systems that must coordinate during the purchase process (reduction of complexity and increase in processing speed). Moving these kinds of features out to individual PaySwarm Authorities/Payment Processors (vs. in the protocol itself) may also increase competition.
RE: "just generate separate listings for each currency that is accepted --
fully keeping any sort of indexes entirely out of the core e-commerce
protocol."
The difficulty with that approach is it does not provide the vendor a
straightforward way to choose a method to tie together each currency
expression of "the price" for the offered product/service unit. If I
understand correctly what you're suggesting, the vendor would (by some
method) determine different prices, each in a separate currency. This begs
the question: How exactly should a vendor in Germany determine the suitable
USD price for a given product/service unit that s/he is selling in both EUR
and USD? The dominant incumbent method tells the vendor to use the
conventional bank's "index" (which they call "THE exchange rate"), which is
really just an index from the WM-Reuters consortium. Maybe that is fine by
this particular vendor, or maybe not. My recommendation is that the
WM-Reuters index ought to appear as just one of the options in the
drop-down menu of indices.
Leaving vendors to fend for themselves seems fine, but only a tiny
proportion will have any criteria in mind or the patience to go and find a
useful index. They will mostly default to whatever is presented. But
presented where? If I am wrong about that, and they don't just default to
what is presented, then purchasers will experience a totally random
diversity of indices in use, which will be both confusing and risky.
Some vendors might eventually band together and created a trusted
webpayments plug-in that standardizes criteria for algorithmic price index
choices -- simpler for both vendors and purchasers. I'm saying this
functionality would be better handled as core, not plug-in. This leaves the
index services themselves as external RESTful services.
RE: "This approach may also include using Ripple's currency, XRP, for
cross-currency purchases"
XRP is "just another index" for exchange rate management
https://ripplecharts.com/grid It is exposed to the same risk which I'll
discuss below. I recommend that the webpayments protocol+Reference
Implementation should abstract from any particular price indexing
solutions, yet still include a way to choose amongst them. It's going to be
important to provide a way for well-formed indexing services to be offered
to vendors as options in a drop-down menu, whenever they need to post and
maintain the prices of units of their offerings in more than one currency.
When I look online to find out how XRP handles transition from any central
bank currency to XRPs, I don't find any explanation of methodology. (Have I
missed the obvious?? Can someone point me to the documentation of the
method for expressing central bank currencies in XRPs at any given moment?)
That methodology is vital. But in any case, once I'm enlightened by
somebody about the XRP methodology, suppose I or someone else don't like
it? Suppose one would like sell stuff to the world in USD or EUR, but
manage the posted prices according to the World Price Index?
http://www.worldeconomics.com/WorldPriceIndex/WPI.efp The have to
implement it themselves.
RE: "Exchanging currencies could be done (if desired) at the local PaySwarm
Authority/Payment Processor or through a "PaySwarm Currency Mint" that may
simply leverage external exchanges. ... My main point is that we should
try to layer these features as much as we can to avoid complexity in the
core protocol.
For several reasons, primarily legal, I recommend not handling this at all
as "currency exhange". Presenting vendors an exchange rate is governed
under international trade law, as well as capital control legislation
within countries https://en.wikipedia.org/wiki/Capital_control. For a
universal web payments an exchange rate approach will result in differing
"user experiences" for different vendors and purchasers, depending on the
jurisdiction they are in. A vendor or purchaser in a country that has
foreign exchange controls can be deemed to be breaking the law by selling
or purchasing online via a site that uses an exchange rate other than what
his/her own government says is the allowed exchange rate. In your country,
today, this is not an issue. But it can very easily be an issue whenever
you government deems it to be so, and changes legislation to that effect.
Regardless of whether or not your government does regulate exchange rates
today, every government has relatively easy-to-use power to regulate
exchange rates. Many countries do regulate exchange rates today. When they
do, then setting or using exchange rates via some method other than an
approved one is illegal. XRP is not resilient to this risk. So while I
understand that what you are suggesting is the obvious approach from the
perspective of the Web Payments application considered in isolation, it's
not an approach that will provide a common user experience out there in the
world of heterogeneous and ever-changing national legal environments. In
sum, that approach is non-resilient.
I'm suggesting to abstract from exchange rates to the more generic concept
of algorithic pricing, of which the exchange rate method is one type. By
working with the more generic concept of "variable pricing", we can keep
the matter entirely within "contracts law". Let the vendor who sells in
more than one currency choose their preferred method of setting their
prices in the various currencies. Sure price controls are legally possible
in any jurisdiction too, but they are far less likely, and they are much
harder for any government to introduce.
On Wed, Nov 6, 2013 at 10:41 AM, Dave Longley notifications@github.comwrote:
The only thing that the standard would need to do is handle a vendor
selecting more than one currency, and if more than one, then also a price
index.The alternative I'm suggesting would be to just generate separate listings
for each currency that is accepted -- fully keeping any sort of indexes
entirely out of the core e-commerce protocol. The accounts used to perform
the transaction would preserve the currency (no exchanging necessary),
moving it from a PaySwarm Financial Account of currency X to another one,
also of currency X. Exchanging currencies could be done (if desired) at the
local PaySwarm Authority/Payment Processor or through a "PaySwarm Currency
Mint" that may simply leverage external exchanges. This approach may also
include using Ripple's currency, XRP, for cross-currency purchases.My main point is that we should try to layer these features as much as we
can to avoid complexity in the core protocol. If we don't have to handle
currency exchange there (by pushing it to another layer or to another
technology like Ripple), it may be best to avoid doing so. That approach
allows currency exchange to happen when desired rather than at the point of
sale; if the desired time is at the point of sale, then using Ripple
may simplify PaySwarm implementations and reduce the number of systems that
must coordinate during the purchase process (reduction of complexity and
increase in processing speed). Moving these kinds of features out to
individual PaySwarm Authorities/Payment Processors (vs. in the protocol
itself) may also increase competition.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-27883719
.
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
http://www.projectmanagementhotel.com/projects/opman-portfolio
jpotvin@opman.ca
Mobile: 819-593-5983
LinkedIn (Google short URL): http://goo.gl/Ssp56
The difficulty with that approach is it does not provide the vendor a
straightforward way to choose a method to tie together each currency
expression of "the price" for the offered product/service unit. If I
understand correctly what you're suggesting, the vendor would (by some
method) determine different prices, each in a separate currency. This begs
the question: How exactly should a vendor in Germany determine the suitable
USD price for a given product/service unit that s/he is selling in both EUR
and USD? The dominant incumbent method tells the vendor to use the
conventional bank's "index" (which they call "THE exchange rate"), which is
really just an index from the WM-Reuters consortium. Maybe that is fine by
this particular vendor, or maybe not. My recommendation is that the
WM-Reuters index ought to appear as just one of the options in the
drop-down menu of indices.
There's a misunderstanding here. The vendor in your example could determine the suitable USD price in the exact same way regardless of whether this feature was in the core protocol or not. It's just a question of whether we require payment processors to implement the feature and provide the service -- or if we let such a service be implemented elsewhere or independently. I'm sure there will be payment processors that will provide the service as a value-add to vendors that choose their services; I'm not convinced that this service should be a mandatory part of the core protocol that every payment processor must implement to be considered compliant. I still think that would be a mistake as it adds unnecessary complexity to a number of use cases that don't involve any need for currency exchange. The core protocol can continue to function just as well if exchange rates, etc. are handled prior to the creation and issuance of listings. I think the concerns can be separated and by doing so, we will increase the ease at which people can implement payment processors, innovate in this space, and compete by providing value-add services.
Dave, I share your objective of modularity and simplicity in both a
standard protocol and in a reference implementation. You say: "there will
be payment processors that will provide the service as a value-add to
vendors that choose their services". Agreed, therefore I recommend that the
protocol standardize the under-structure for how that is done. So I think
for the most part we're in agreement in principle, but there's discussion
still required to delineate the actual functional boundary:
RE: "I'm not convinced that this service should be a mandatory part of the
core protocol that every payment processor must implement to be considered
compliant.
Prior to the 1970s money was widely understood have three essential use
cases: (1) a medium of exchange, (2) a unit of account, (3) a standard of
deferred payment (requiring that it be a stable store of value). A
Universal Payments System Standard would encompass all three of those. The
thorny one is (3), and it's almost been forgotten about in our fiat-fed
world. But to leave the enabling of this use case out of the scope of the
standard, is to make the standard either incomplete (resulting in ad
hocism), or to render it as a Fiat Money Payments System Standard only.
Incomplete Payments System Standard: IF the payments system standard does
not address how a compliant reference implementation would offer choice
amongst purchasing power indices, then the standard fails to encompass that
third essential use case of money. A universal standard must not dictate
which purchasing power indices must be used, nor specifiy the algorithms
producing those indices. But the method for identifying and calling and
applying purchasing power price index algorithms should be standardized. If
the standard does not do this, then developers of payment processors will
come up their own ad hoc ways to implement choice of price index, and more
likely, most will just hard-code to the incumbent index from WM-Reuters
designed and operated by top predators. Both of those will be called "W3C
Standard Compliant". But then where would a standard for identifying and
calling and applying purchasing power price index algorithms be situated?
There isn't anywhere. When a vendor changes from one payment system to
another, or sells through more than one portal, their pricing will be
affected.
Fiat Money Payments System Standard: IF the payments system standard
explicitly declares that it shall use the incumbent inter-currency price
indexing system then this so-called "standard" is encumbered to one
consortium's control ( specifically the WM-Reuters Spot Index
http://www.wmcompany.com/pdfs/026808.pdf ). And since the institutions that
operate the WM-Reuters index do not have extensions for autonomous
currencies, then if the supplier of a web payments solution wants to let
vendors accept both central bank and autonomous currencies, they would have
to choose the other valuation indices on the vendor's behalf. But what
standard-compliant criteria may be used by a payments application developer
to include any of those other alt indices? The past two generations
especially, i.e. since the 1970s, have been shaped by the conceptual
premises of a fiat-only speculative currency world. This has come to appear
as the "tabula rasa" upon which the very substructures of monetary value
are built -- Bitcoin suffers the same gap:
Q: "What's the purchasing power of a Bitcoin?"
A: "Ah, whatever. More today I hear!"
A truly "Universal" Payments System Standard will enable a vendor who
accepts more than one currency to easily select a preferred purchasing
power index, the one the vendor trusts as the most likely to stablize
purchasing power across the different currencies. Making such a choice of
index, this vendor is a proactive autonomous participant in "the market"
who is not satisfied to have relative prices dictated to his or her
business by the Deutchbanks and GoldmanSachs of officialdom, nor by the
MtGox's and Ripples of the alt world. Quite simplly, this vendor maintains
full competitive autonomy to set his or her prices.
RE: "I still think that would be a mistake as it adds unnecessary
complexity to a number of use cases that don't involve any need for
currency exchange. The core protocol can continue to function just as well
if exchange rates, etc. are handled prior to the creation and issuance of
listings.
This inter-currency purchasing power problem is inherent to general
monetary theory, so while I am calling attention to it and suggested ways
to handle it, I am not attempting to impose it. It's "unfortunately
mandatory" to deal with identifying and pulling in and applying purchasing
power price index algorithms, if a payments system is to be market-neutral.
If what I am suggesting seems like adding complexity, they I have not
communicated it very well. Ensuring users have choice does involve
interfacing with complexity, but it also protect payments systems
developers and users from the greater complexity of having to fish in an
ocean of ad hocism: i.e. no standard on that aspect.
RE: "I think the concerns can be separated and by doing so, we will
increase the ease at which people can implement payment processors,
innovate in this space, and compete by providing value-add services.
The sort of simplicity you are inadvertently advocating is the sort of
simplicity achieved with tying a "standard" to the assumption that
everybody's using Microsoft Windows.
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman http://goo.gl/Ssp56
Hey @dlongley, I think we're going to have to re-think the way we're doing dynamic pricing in the system. I don't know if continuously regenerating pricing information by regenerating listings is a good approach. For example, if you wanted pricing information to be valid minute-to-minute as well as your listings to be distributed widely, you don't leave much time for the listings to be in flight. That is, any listing that needs to be valid on a minute-by-minute basis can only really have a listing validity period of a minute. That doesn't allow the listing to get distributed very widely before it becomes invalid.
Allowing the vendor to tie their price to an index of some sort would allow the price to be discovered at the time of sale, rather than at the time of listing creation. I realize that this would require some re-thinking and it's impact would be non-trivial. That said, I think we should look into it a bit more deeply. I share @jpotvin's concerns.
RE: "The downside with this approach is that the price will never be truly
known except at the time of sale."
As things are everywhere today anyways, when a transaction involves more
than one currency the price is not known to either party until, or often
only well after the time of sale. Example: When you checked into your hotel
for your most recent conference in Europe and staff took the number on your
credit card, they quoted you their hotel rate in EUR, and you might have
calculated that in USD using the conversion rate that you got when changing
cash at the airport upon arrival. A few days later when you checked out,
the hotel processed the payment, and a few hours later perhaps your credit
card company applied its favourite purchasing power index, which they call
the USD-to-EUR exchange rate -- which is based on the WM-Reuters Spot
Index. Ignoring the credit card processing fees (which you may or may not
keep abreast of), the actual "price" amount for hotel services that were
billed to your credit card account was certainly not the exact price you
worked out based on what your were told at check-in time. Usually it does
not vary much. Sometimes it's surprising.
RE: "There are problems here, for example, if the price deviates by more
than a few percentage points from the one listed to the buyer."
This constitutes the competitive difference upon which various index
suppliers compete. A vendor who chooses an index that does deviate more
than purchasers like, might irritate their customers. If the vendor
chooses, they can authenticate to the web paymenst module of their site and
switch to a more stable purchasing power index. How will they know what's
more stable? Any payments processor will have access to the historical
index information, and can easily display and provide automated statistical
information on the comparative stability of each index. Some vendors will
prefer to choose an index based on some other priority besides overall
systemic stability -- for some, instability that tracks some particular
set of commodity prices might be better, and they would just explain to
their customers why they must pass along that + & - risk to the customers.
(Hence the name Free/Libre Commerce.)
RE: Providing "current pricing" information will be problematic because
prices could change from a microsecond to microsecond basis, as it does in
high frequency trading.
For this reason I prefer a purchasing power price index calculated with a
time-based moving average, which could be, say 1-hour, 1-day, depending on
the index design. Some indexes, like the particular one that I prefer,
would use a 3-year moving average, as it is optimized for deep stability
tied to fundamental trends in economic productive capacity within the
geographical boundaries of each currency zone. Others would want a
real-time spot index. This is a vendor's choice to make, and a purchaser's
choice to be attracted to or repulsed by.
RE: I don't think the solution has to be that complex. My assumption is
that you just do a REST call to a URL to get the current price.
Correction, I think: You just do a REST call to a URL to get the current
vendor-selected purchasing power index, which is then use by the processor
to generate current price from vendor's "reference" price. Since I'm in
Canada, let's say I would put the price of some widget at CAD$100, and
choose the ER Index to generate the prices in USD and EUR, right now and
going forward.
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman http://goo.gl/Ssp56
I think we're going to have to re-think the way we're doing dynamic pricing in the system. I don't know if continuously regenerating pricing information by regenerating listings is a good approach. For example, if you wanted pricing information to be valid minute-to-minute as well as your listings to be distributed widely, you don't leave much time for the listings to be in flight. That is, any listing that needs to be valid on a minute-by-minute basis can only really have a listing validity period of a minute. That doesn't allow the listing to get distributed very widely before it becomes invalid.
Allowing the vendor to tie their price to an index of some sort would allow the price to be discovered at the time of sale, rather than at the time of listing creation. I realize that this would require some re-thinking and it's impact would be non-trivial. That said, I think we should look into it a bit more deeply. I share @jpotvin's concerns.
It's also important to remember that we considered trying to put algorithmic pricing and currency exchange into the core protocol early on -- and the reasons why we opted to avoid the complexity, at least for the first version of the standard. Some of the core use cases for Web Payments were difficult to implement.
Take for instance, the use case of in-app or in-game payments. We need to enable applications and games to be able to display prices to their customers and also keep those customers in the application/game when performing a purchase (without having to send them off to their payment processor for confirmation). With the current design, this is achievable with the possible exception of having the prices be slightly off because taxes haven't been accounted for. However, if customers opt-in to "one-click" purchases of this sort, we expect that they would be ok with "Product X costs $0.50+tax" before clicking.
I don't think the same could be said about not knowing the price at all. So, the question then becomes, how do you get the price information? Well, as far as I can tell, based on the current design and the proposed changes here, we'd be looking at having to:
- Expose who the buyer's payment processor is to the vendor in order to allow them to make a REST call to obtain a price -- as it is the buyer's payment processor that handles the sale. (Note: Since these prices can change minute to minute, it would only be a price estimate), or
- Require the vendor to make a REST call to their own payment processor whenever they wanted to display a price.
In either of these cases, we're adding a tremendous amount of overhead to the purchase process and to payment processors. With the current design, whenever a price needs to be displayed to a user, no payment processor needs to be contacted. With the proposed changes, payment processors must be contacted for every price display. Some vendors may implement caching schemes, but there's no guarantee and, again, if we're talking about minute-to-minute price changes, caching is unlikely to be that useful. With the current design, vendors instead would be interfacing with services whose (perhaps) sole purpose is to provide pricing information. These services wouldn't have to be tied to payment processors in any way, either.
Keep in mind that if we start requiring mandatory services on payment processors for price resolution -- that a lot of vendors will use them even if they aren't necessary. It could easily become the standard process for price display on websites because it's the easiest thing to do. You just do it one way -- and it will always work, regardless of whether or not you need the fancy price indexing features. I suppose we could engineer the protocol around this to reject attempts to resolve prices that don't use price indexes, but again, that adds more complexity (and confusion).
I agree that regenerating pricing information and reissuing listings has its own set of issues, but it was chosen because it was the lesser of two evils. Furthermore, it only applies to those vendors that actually need to do minute-to-minute pricing; these vendors likely do not constitute a majority in the overall Web Payments market.
To be clear, I'm not strictly opposed to integrating these features into the core protocol. I just don't think we've come up with a scalable solution to this problem yet. I think the most likely effect of any of the proposals we've seen so far would be a rejection of the standard by potential payment processor implementers. Either that, or they just wouldn't implement the price indexing feature. A majority of them, I believe, won't need the feature. I would expect that only the largest and most generic payment processors would have a desire to implement it. At least, with the current approach, vendors can use whatever price indexes they want -- and the results will be exactly the same. Furthermore, any payment processor will work.
For this reason I prefer a purchasing power price index calculated with a
time-based moving average, which could be, say 1-hour, 1-day, depending on
the index design. Some indexes, like the particular one that I prefer,
would use a 3-year moving average, as it is optimized for deep stability
tied to fundamental trends in economic productive capacity within the
geographical boundaries of each currency zone. Others would want a
real-time spot index. This is a vendor's choice to make, and a purchaser's
choice to be attracted to or repulsed by.
It's also worth noting that in the current design, there is no need for the vendor to contact their payment processor in order to issue assets or listings. With the proposed changes, this would also no longer be the case (if they are using the price indexing feature). This adds a further burden onto payment processors that could be avoided by letting the vendor choose whatever service they wanted to convert their price index choice/algorithm into an actual price that they would then put in their listing. I don't think most buyers care which price index the vendor has chosen. Rather, all they want to see is the actual price (perhaps sans tax in the in-app/in-game case) for the thing they want to purchase. Perhaps this is what you're getting at -- they would make decisions based on the effect of the vendor's choice, however, this is true regardless of which approach is taken to address this problem.
RE: "I'm not strictly opposed to integrating these features into the core
protocol. I just don't think we've come up with a scalable solution to this
problem yet"
Dave, I still need to read through your two messages today thoughtfully,
but let me first ask a couple of quick questions for clarity:
- If a vendor chooses to receive payment in only one currency, then any
multi-currency indexing functionality stays dormant. No index choice to
make. That's okay, correct? Or is there still a background problem you
anticipate within the system? - If a vendor chooses to receive payment in more than one currency, they
could choose the "official exchange rate" (WM-Reuters spot exchange rate).
This is what the incumbent model does today, directly or indiredtly. But is
there a procedural problem introduced by putting that extra step in their
way?
BTW, in my imagination, each vendor would only set up their rule for how
their prices are handled, when the set up their account. And later they
could log in to change settings it if they wish. There's no need for the
vendor to choose a price index for every item class on offer.
I'll get back to your messages
joseph
On Wed, Nov 20, 2013 at 10:13 AM, Dave Longley notifications@github.comwrote:
For this reason I prefer a purchasing power price index calculated with a
time-based moving average, which could be, say 1-hour, 1-day, depending on
the index design. Some indexes, like the particular one that I prefer,
would use a 3-year moving average, as it is optimized for deep stability
tied to fundamental trends in economic productive capacity within the
geographical boundaries of each currency zone. Others would want a
real-time spot index. This is a vendor's choice to make, and a purchaser's
choice to be attracted to or repulsed by.It's also worth noting that in the current design, there is no need for
the vendor to contact their payment processor in order to issue assets or
listings. With the proposed changes, this would also no longer be the case
(if they are using the price indexing feature). This adds a further burden
onto payment processors that could be avoided by letting the vendor choose
whatever service they wanted to convert their price index choice/algorithm
into an actual price that they would then put in their listing. I don't
think most buyers care which price index the vendor has chosen. Rather, all
they want to see is the actual price (perhaps sans tax in the
in-app/in-game case) for the thing they want to purchase. Perhaps this is
what you're getting at -- they would make decisions based on the effect of
the vendor's choice, however, this is true regardless of which approach is
taken to solve this problem.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-28896840
.
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
http://www.projectmanagementhotel.com/projects/opman-portfolio
jpotvin@opman.ca
Mobile: 819-593-5983
LinkedIn (Google short URL): http://goo.gl/Ssp56
- If a vendor chooses to receive payment in only one currency, then any
multi-currency indexing functionality stays dormant. No index choice to
make. That's okay, correct? Or is there still a background problem you
anticipate within the system?
One potential problem is with vendors choosing "one path" (via common software libraries) to display prices that results in a check with a payment processor to display the price. The other problem is with systems that want to use payswarm without the multi-currency indexing functionality but can't because they aren't compliant without it. These would be systems that would rarely, if ever, need to deal with multi-currency issues. If those issues are dealt with outside of the core protocol, then they would have nothing to implement but would still interoperate 100% of the time, even for the rare multi-currency transactions.
- If a vendor chooses to receive payment in more than one currency, they
could choose the "official exchange rate" (WM-Reuters spot exchange rate).
This is what the incumbent model does today, directly or indiredtly. But is
there a procedural problem introduced by putting that extra step in their
way?
From what I can tell, the number of steps is identical whether the price index information is part of the core protocol or not. For vendors, any difference in where those steps occur would be hidden by software libraries. The only exception to this would be in listing validity vs. price validity. In the current system, listings could expire more quickly (if desired) but prices would be stable (for display) and with the current alternative proposals, listings could be longer lasting, but prices would require an additional check. It may take two checks, actually, one for displaying the product on the vendor's site and one for actual purchase confirmation on the payment processor's site. The second check could be avoided by introducing another layer of complexity where quotes are digitally signed by payment processors... however, that introduces its own set of new problems to solve.
In the end, the difference, technologically speaking, is between asking a service (any independent service) for a price that is guaranteed to be valid for a period of time the vendor selects or asking a service that must be part of a payment processor for a price every time a price is displayed or some possibly lower frequency based on whether or not caches can be relied upon, etc.
BTW, in my imagination, each vendor would only set up their rule for how
their prices are handled, when the set up their account. And later they
could log in to change settings it if they wish. There's no need for the
vendor to choose a price index for every item class on offer.
This could be done either with the existing system by choosing a payment processor that elects to provide the feature (on top of the core protocol as value-add/incentive to get more vendors signed up) or as a separate independent service the vendor may sign up with. In either case, the vendor would likely only deal with this at sign up time and a software library would handle the rest for them.
In other words, I don't think the issue is with user experience (vendor or buyer) for any of the approaches we're discussing. The only possible exception I can think of at the moment would be with leaking customer payment processor information to the vendor where it could be avoided via a different approach. In any case, the main differences, IMO, are in payment processor implementation difficulty and scalability.
RE: "The other problem is with systems that want to use payswarm without
the multi-currency indexing functionality but can't because they aren't
compliant without it."
I am trying to imagine any rationale for an online payments system without
the price indexing option. It seems to me that a payments system without
the availability of price indexing would be restricting vendor choice in
(a) pricing method; (b) currency. I'll try to say this in a generalized
way, in the form of a draft suggested payments system standard requirement:
"A payments system standard shall respect and enable vendor freedom of
choice in pricing method, and in currency. Any vendor may implement fixed,
differentiated or indexed pricing. And any vendor may designate one or more
currencies in which to receive payment. Following from this, any purchaser
may issue payments in any of a vendor's designated currencies."
Let me explain the rationale for these two aspects:
(a) Even if a vendor chooses to receive payments in only one currency, they
might want to have variable pricing indexed to something. A standards-based
payments system can make it very simple to set this up in a standardized
way. Even if a vendor wants to invent their own custom index, that's fine.
They create their custom index, host is somewhere, and present a RESTful
data supply in a standard-compliant way. From the payments system side,
they select their custom price index from the list, instead of one of the
other existing standard-compliant indices offered. This makes indexing
simple for vendors to handle generally, and makes it transparent for
purchasers that the price is indexed. So, this is relevant even when the
vendor chooses to be paid only in a single currency.
(b) Whenever a vendor chooses to receive payments in more than one
currency, then a price index is logically essential -- this is not a matter
of indexing itself being preferred. When indexing itself is a logical
necessity, then choice of index must be enabled. A bank-posted currency
"exchange rate" is one possible index to choose, but (unlike general
perceptions) it is not the only reasonable choice. For more about the
significance of choice in currency, see pgs 17-19 in:
http://library.mises.org/books/Friedrich%20A%20Hayek/Choice%20in%20Currency.pdf
RE: From what I can tell, the number of steps is identical whether the
price index information is part of the core protocol or not.
I think the core protocol would need to express:
(a) the way price indices must be presented in order for any
standard-compliant payments system to draw upon them;
(b) the minimum requirements for a standard-compliant payments system to
enable vendors to choose currencies and price indices from amongst those
supplied in the competitive "market for currencies" and in the separate
competitive "market for price indices"; and
(c) the minimum requirements for a standard-compliant payments system to
enable purchasers to choose from amongst the currencies that vendors have
selected.
RE: with the current alternative proposals, listings could be longer
lasting, but prices would require an additional check. It may take two
checks, actually, one for displaying the product on the vendor's site and
one for actual purchase confirmation on the payment processor's site. The
second check could be avoided by introducing another layer of complexity
where quotes are digitally signed by payment processors... however, that
introduces its own set of new problems to solve.
Once the purchaser commits to a transaction at a posted price, that price
ought to be the one that follows though. This is an improvement on the
incumbent system for inter-currency purchases that lets the exchange rate
index vary the actual "Currency Y" price billed to one's credit card, from
the "Currency X" price that the purchaser committed to. If such price
assurance introduces too much complexity at this time, then at least the
purchaser can be informed that the posted price is indexed (which it is
today, but the purchaser is just assumed to know about exchange rate
volatility).
RE: In other words, I don't think the issue is with user experience (vendor
or buyer) for any of the approaches we're discussing.
Agreed, the issue is what layer this is enabled at. If it's described at
the layer of the web payments standard and thus enabled in the reference
implementation, then the essential elements can be standardized and
pre-built. If it is all left to each payments system implementer, then the
essential elements will not be standardized, and efforts will be widely
disbursed, redundant and heterogeneous. To me it seems extremely helpful if
this were to be standardized.
RE: "the main differences, IMO, are in payment processor implementation
difficulty and scalability"
Understood. The main differences I'm concerned with are USER freedom of
choice in pricing method and in currency; and assuring those, then payment
processor SUPPLIER's implementation simplicity and scalability.
Joseph Potvin http://goo.gl/Ssp56
@jpotvin If I may paraphrase what @dlongley is saying: Everything you're saying is well and good, but there are very significant technical issues that are created when we build price indexing into the core protocol.
The last time we tried to address this issue, the technical hurdles spiraled out to the point of it being an existential crisis for the protocol. Sure, we could implement price indexing, but the solution was so complicated that we were concerned that it would cause either 1) the protocol to be rejected outright, or 2) implementers to skip implementing the price indexing feature (which they typically do for complex features).
That's not to say that we don't try to work it out. At present, my opinion is a mix of both of your positions. I think we do need price indexing in the core protocol in some way as having people generate listings every several minutes is a non-starter. That said, we need to make sure that price indexing doesn't cause instability in the overall system and that it's not that technically complex to implement. It's a fringe feature that only a few will use and it's okay if price indexes fail from time to time, or we have a decentralized price indexing algorithm that is moderately simple to implement.
In any case, we should discuss this on this week's upcoming telecon.
RE: we should discuss this on this week's upcoming telecon.
I'll be there, thanks.
RE: The last time we tried to address this issue, the technical hurdles
spiraled out to the point of it being an existential crisis for the
protocol.
RE: or we have a decentralized price indexing algorithm that is moderately
simple to implement
Is there somewhere we can read about the previous effort? Did you try to
incorporate the indexing itself? That would be terribly complex. I'd say
there should not be even a single price indexing algorithm within the
standard or within any "reference" implementation. What I recommend is that
openness should be enabled in both the standard and any reference
implementation to a "market for price indexing algorithms". Agreed, it must
be very simple for vendors to choose amongst indices "out there". Their
chosen index can be the bank-published exchange rates if the vendor likes.
But it ought to be just as easily some other.
My recommendation is to have "the ability to handle price indexing" in the
core protocol, but definitely not to have any particular "price index"
algorithm in the core protocol.
Let me give a tangible example where a particular external price index is
embedded within a payments processor's system in a manner that is opaque to
users, and that leaves all vendors exposed to the machinations of some
un-named external private consortium producing the index.
From digital payments service Stripe, I received the following notice:
On Wed, Nov 13, 2013 at 1:06 PM, Xxx <Xxx@stripe.com> wrote:
Hi,
We noticed that you've connected a bank account for CAD funds with
Stripe
and wanted to let you know that you can now also accept USD with no
additional configuration necessary.
We'll automatically handle all conversions and deposit the money in your
preferred bank account. Please note that currency conversions have an
additional fee of 2%. You can always connect a USD bank account and
we'll
deposit USD funds there without conversion.
You can edit your bank account settings here:
https://manage.stripe.com/account/transfers.
If you have any questions or comments, we'd love to hear from you —
thanks
for using Stripe!
Thanks,
Xxx
I'm not talking about the issue of their 2% service fee. But I did ask the
following:
On Wed, Nov 13, 2013 at 11:39 AM, Joseph Potvin wrote:
RE: "We'll automatically handle all conversions and deposit the money
in
your preferred bank account. Please note that currency conversions
have an
additional fee of 2%."
Hello Xxx, Can you let me know what method will be used for any
conversions?
What will be the actual data source of the CAD vs USD conversion rate
that's
applied?
Thanks,
Joseph Potvin
And received the following reply:
Wed, Nov 13, 2013 at 5:25 PM, <Xxx@stripe.com> wrote:
Hi Joseph,
We pass on the wholesale foreign exchange rates that we get from our
banking partners, which is the exchange rate at the time of the charge
transaction.
Hope this helps!
Xxx
Exactly. And as noted earlier, those banking partners are probably relying
on: http://www.wmcompany.com/wmr/Partners/IndexCompilers/index.htm
I have no problem at all with any vendor choosing this consortium, and I
have no criticism to offer about WM-Reuters' methodology. It is what it is.
I do think it's a bit of a problem if this choice is made unilaterally by a
payments processor, rather than left to me as a vendor. I think it would be
a much deeper problem for either a universal web payments standard or any
"reference" implementation of a standard to make this choice a priori. This
is just to say that the standard and the reference implementation should
not be encumbered to a particular price indexing consortium.
RE: generate listings every several minutes is a non-starter
Agreed. I have not looked at how Payswarm fetches the prices to display,
but if displayed price were a computed field at the moment of page
generation for a browser, time granularity wouldn't matter, I think. There
would be additional processing cost -- that's a downside.
RE: We need to make sure that price indexing doesn't cause instability in
the overall system and that it's not that technically complex to implement.
Agreed.
RE: It's a fringe feature that only a few will use
Not sure what you mean. Exchange rate indexing is not fringe. And variable
pricing even when selling in a single currency is normal in many markets,
just like gasoline at the pump (where I live we check
http://www.ottawagasprices.com/ ) or airline tickets online. Many vendors
in markets that tolerate variable pricing do index their posted prices to
declared indicators, but others will say: "Call us for pricing". That's
fine, but not very scalable for the web, and not very transparent. Consider
a vendor of XYZ services selling only in the their local market, but whose
service makes use of expensive materials that are imported (wood, food,
chemical,...). It's normal for such vendors to link their service price to
the change in the local currency cost of the things they import. Will
online vendors who use variable pricing have to log into their sites each
day to repost their prices? It might be better if the web payments
implementation will let them set up some sort of algorithm to reduce this
tedius work. The basic functional logic of setting this up is common across
all web payments implementations, so it also might be best to put the
common enabling components into core.
Is the question only: How to do this in a simple way? It would be helpful
to know more about what caused the "existential crisis for the protocol"
the last time this issue was tackled.
Joseph
Some days ago @dlongley said: "With the proposed changes, payment
processors must be contacted for every price display. Some vendors may
implement caching schemes, but there's no guarantee and, again, if we're
talking about minute-to-minute price changes, caching is unlikely to be
that useful."
Today I @jpotvin said: "I have not looked at how Payswarm fetches the
prices to display, but if displayed price were a computed field at the
moment of page generation for a browser, time granularity wouldn't matter,
I think. There would be additional processing cost -- that's a downside."
I want to revise what I said about the operational aspect, because thinking
about this further, I see what Dave is concerned about: computing each and
every price during page generation with a call out to an external site
would involve: (a) too much on-the-fly processing and network traffic for
the enormous deployment scale that we're discussing; and (b) too high a
risk of failure when pulling in the chosen price index on-the-fly from an
external location experiences issues, resulting in failed price displays
and user frustration.
So leaving out minute-to-minute price index updates, if a price index cache
were updated every hour or six hours, it would be necessary to determine
which indices from "out there" need to get cached. Perhaps this could be
accomplished by some criterion whereby if the volume of ad hoc calls
through a payments processor to an external price index starts to cause
more traffic than automated hourly updating of the cache with that index
would cause, then that index gets added to the cache. It's a tiny amount of
data to cache. The rule can be put in reverse for an index that is being
cached, but that loses demand, so it's relegated to external calls only.
I'd recommend that a standard conformance rule can also be used as a
criterion for listing or not listing an index, such as is implemented by
the Comprehensive R Archive Network (CRAN) for quality control of R
packages that CRAN is prepared to list:
"A package needs to pass these checks to be admitted to CRAN, and needs to
continue to pass when new versions of R are released, or it is removed from
CRAN. Once a package is on CRAN it is checked daily to see if it is still
passing checks as changes are made to R. These results can be viewed at
http://cran.r-project.org/web/checks/check_summary_by_maintainer.html#summary_by_maintainer
"
More info about that:
http://www.projectmanagementhotel.com/projects/course-free-libre-open/wiki/Model_of_Rigorous_FreeLibreOpen_Control_at_CRAN_%28The_Comprehensive_R_Archive_Network%29
In the case of a price index that even a few vendors rely on, it should not
be just delisted, but at least a little "good housekeeping" or
"non-compliance" notifier should be associated with each listed index.
Joseph Potvin
http://goo.gl/Ssp56
Once the purchaser commits to a transaction at a posted price, that price
ought to be the one that follows though.
What this translates to, IMO, is a non-repudiable listing that contains the posted price. This calls into question the value of having price index information in the listing itself (as proposed early on above). In order to guarantee the purchaser the posted price, the listing must contain the posted price, not a mere abstraction that may or may not yield that price once reified.
Let me recap what I've understood to be the two different systems proposed thus far. Here's what I think the process that kicks off a purchase looks like for each one:
In system A:
- Vendor configures their software to use an independent price index service S to use to obtain listing prices.
- Vendor creates a new listing; their software uses S to obtain the price and then digitally-signs and stores the listing.
- Vendor's software displays the listing on the vendor's site.
- If a customer decides to purchase, they give the digitally-signed listing to their own payment processor and the purchase occurs.
In system B:
- Vendor creates a new listing that contains a link to an independent price index service S.
- Vendor's software sends the listing to the vendor's payment processor.
- Vendor's payment processor uses S to obtain the price for the listing, rewrites it, then sends it back to the vendor's software.
- Vendor's software digitally-signs and stores the listing.
- Vendor's software displays the listing on the vendor's site.
- If a customer decides to purchase, they give the digitally-signed listing to their own payment processor and the purchase occurs.
In order for the vendor to update their prices, they configure their software to repeat step 2 for system A and steps 2-4 for system B.
In both systems, the same digitally-signed listing is stored with the vendor for price display. This is the same listing that is distributed to the purchaser and that ultimately ends up with their payment processor should they elect to purchase. The only difference is in how that listing is generated.
In system A, the listing is generated once some software takes input from the vendor and talks with S. The vendor trusts S to output a reasonable price as once the software takes over there can't be a human in the loop. In system B, the listing is generated by the vendor and contains price index information. Then it travels through an additional party (the payment processor) before reaching S and then round tripping all the way back. Then the vendor implicitly trusts both parties will do their job properly, again, because a human can't be in the loop.
The end result for the vendor is the same, but system A is more efficient, requires less trust, and because of reduced complexity, is less error prone. System A also allows for standards regarding the protocol used for communicating with price index services to evolve independently of payment processors. Furthermore, it doesn't require that price indexing information appear in listings.
Now, from what I can tell, there may be some variant ideas for system B that have floated around during this discussion. There has also been discussion about caching that could be performed by payment processors to reduce their need to call out to price indexing services. Of course, never having to do that at all is more efficient both in real time and in implementation complexity -- so we ought to be discussing the need for payment processors to be involved in the loop at all if the end result is going to be the same. The main advantage to that approach that I've seen thus far is that a vendor can go to a single place to configure both their payment preferences and their price index choices. However, that seems to me to be a value-add service that payment processors could easily provide on their own -- and likely would if they were being used in an area that required price indexing to begin with. That approach, though, doesn't impose an unnecessary implementation burden upon payment processors that do not need to deal with these issues.
There has been much more said in this thread since my last response, so I'll have to catch up when I can, but the above jumped out at me as the crux of the issue, at least for me.
I am trying to imagine any rationale for an online payments system without
the price indexing option. It seems to me that a payments system without
the availability of price indexing would be restricting vendor choice in
(a) pricing method; (b) currency.
Not requiring that price indexing be part of the core protocol is not the same thing as being "without a pricing indexing option." When I say "core protocol," I mean having price indexing information be in the listing that the purchaser gives to the payment processor such that the payment processor must use that price index to determine pricing. Instead, price indexing could be used in a way that doesn't require payment processors to be directly involved.
This doesn't preclude standardizing a price index service protocol either. It just doesn't have to be something that payment processors must understand. It could be an option that vendors could take advantage of via other services.
To further clarify, we could put out an additional spec in the Web Payments WG that specifies how to talk to price indexing services in a standard way so that vendors can do that before generating their listings if they want to.
I think we do need price indexing in the core protocol in some way as having people generate listings every several minutes is a non-starter.
I disagree. I don't see this as being easily avoided either. The alternatives being suggested so far still require this to happen, it just happens in a more inefficient way than it would with the current design.
I think we're getting a bit lost here and some clarity on what a listing is might help. A listing is a promise to sell a particular asset at a particular price (and currency) during a particular time window. Therefore, if you want to be able to give a purchaser such a non-repudiable note for a particular asset and price, and your prices change every several minutes, then we're talking about generating listings every several minutes.
The alternative is generation of a listing on-demand (likely with a backing cache). At capacity, however, the result is the same.
If it helps to consider it from a high-level use case:
A buyer is looking for an asset to buy. They go to a web page that will display such an asset. The page must generate information about that asset and a price for it so the buyer can, at minimum, make a preliminary purchase decision (for in-app/in-game purchases the decision will not need an extra confirmation step). Whatever details the page generates must be what the buyer gets (or very close to it) when they elect to make a purchase.
In PaySwarm, we call those "details" the asset and listing and we guarantee that they are unchanged when the buyer submits them to initiate a purchase by digitally-signing them before they are viewed. Every "offer" of this type is a listing, and whenever the offer changes, a new listing must be generated. Any scenario that involves changing offers that buyers are viewing every several minutes involves generating listings every several minutes.
RE: "we could put out an additional spec in the Web Payments WG that
specifies how to talk to price indexing services in a standard way so that
vendors can do that before generating their listings if they want to"
I'm certainly open to that in principle. I'll need to think through the
processes and architectures described in your previous message before I
have a view to share back.
RE: Not requiring that price indexing be part of the core protocol is not
the same thing as being "without a pricing indexing option."
Agreed.
Very much appreciate the thoughtful assessment, thanks.
Joseph Potvin
Let me preface this feedback by clarifying that the scope of my
intervention derives from a concern only about satisfying the two
high-level use cases: (a) vendor choice in currency; and (b) vendor choice
in pricing method. I defer to the very thoughtful efforts of @dlongley,
@msporny et.al. about how these could be elegantly accomplished. Our
discussion about specific implementation methods derives from mutual
efforts to reckon how these might actually play out in terms of whether (in
fact) vendors, or (in fact) suppliers of payments systems, will be
positioned to make those two choices. Ensuring genuine choice in the hands
of vendors will depend upon the functional ease and equivalency over which
currencies they post their prices in, and that they can receive payment in,
as well as the functional ease and equivalency with which they can choose
pricing methods. (This includes their realizing that an "official exchange
rate" is just one of many potential price indices to choose from -- a
matter of transparency.) Beyond technical accomplishment of functional ease
and equivalency, its intersection with business architecture will determine
whether technical ease and equivalency really carries through to deployed
environments. My concern is with how easy or difficult it will be, via one
implementation/deployment method vs another, for skewed power structures in
the payments processing market to de facto restrict vendor choice in
currency and pricing method, regardless of what any standard or reference
implementation (or law) provides.
RE: a non-repudiable listing that contains the posted price
It seems to me that would be consistent with the usual store-front law that
the posted price on-the-shelf is what the vendor must go with (except where
someone might have switched tags).
RE: the two different systems proposed thus far: system A; system B:
Let's describe System 0, the current state of things. (Let me know if you
think this is accurate.)
Financial institution of the Payments system designer/operator supplies
the price index service WMR
Payments system designer/operator configures their software to use the
price index service WMR to use to process transaction prices.
Vendor creates a new listing; their software does not include any
reference to the WMR index
Vendor's software digitally-signs and stores the listing.
Vendor's software displays the listing on the vendor's site.
If a customer decides to purchase, they give the digitally-signed
listing to their own payment processor, the processor applies the WMR index
and sends the resulting abount to the Vendor's account for the purchase to
occur.
I think I'd express your system A as follows (Again, tell me if I've messed
something up):
Vendor configures their software to express pricing in one or more
currencies, and to use an external price index service S to calibrate each
listing price in multiple currencies and/or through time.
Vendor creates a new listing, and gives it a single reference price in
a single reference currency at a single moment (Vendor can always update
this);
Vendor's software draws index data from S to interpret the single
reference price in all Vendor-selected currencies, repeating this on a
given schedule. Each update is digitally-signed by the Vendor's software.
Vendor's software displays the listing on the vendor's site, with a
reference to the price index used (eg it could refer to their bank's
exchange rate) [1]
Customer using Vendor's site chooses a payment currency from amongst
those determined by the Vendor (like choosing a language), and then prices
are displayed in that currency.
If a customer decides to purchase, they give the digitally-signed
listing priced in their chosen currency to their own payment processor and
the purchase occurs.
[1] RE: System A ... doesn't require that price indexing information
appear in listings.
Hmm, it should I think. Just as a the paper receipt from the currency
changer at the airport ought to tell me the exchange rate that's been
applied.
Joseph Potvin
On Mon, Nov 25, 2013 at 11:27 AM, Dave Longley notifications@github.comwrote:
Once the purchaser commits to a transaction at a posted price, that price
ought to be the one that follows though.What this translates to, IMO, is a non-repudiable listing that contains
the posted price. This calls into question the value of having price index
information in the listing itself (as proposed early on above). In order to
guarantee the purchaser the posted price, the listing must contain the
posted price, not a mere abstraction that may or may not yield that price
once reified.Let me recap what I've understood to be the two different systems proposed
thus far. Here's what I think the process that kicks off a purchase looks
like for each one:In system A:
- Vendor configures their software to use an independent price index
service S to use to obtain listing prices.- Vendor creates a new listing; their software uses S to obtain the
price and then digitally-signs and stores the listing.- Vendor's software displays the listing on the vendor's site.
- If a customer decides to purchase, they give the digitally-signed
listing to their own payment processor and the purchase occurs.Note: The vendor configures their software to update prices as often as
they like, which causes steps 2 and 3 to be repeated automatically.In system B:
- Vendor creates a new listing that contains a link to an independent
price index service S.- Vendor's software sends the listing to the vendor's payment
processor.- Vendor's payment processor uses S to obtain the price for the
listing, rewrites it, then sends it back to the vendor's software.- Vendor's software digitally-signs and stores the listing.
- Vendor's software displays the listing on the vendor's site.
- If a customer decides to purchase, they give the digitally-signed
listing to their own payment processor and the purchase occurs.In order for the vendor to update their prices, they configure their
software to repeat step 2 for system A and steps 1-4 for system B.There are several things that are important to note here. In both systems,
the same digitally-signed listing is stored with the vendor for price
display. This is the same listing that is distributed to the purchaser and
that ultimately ends up with their payment processor should they elect to
purchase. The only difference is in how that listing is generated.In system A, the listing is generated once some software takes input from
the vendor and talks with S. The vendor trusts S to output a
reasonable price as once the software takes over their can't be a human in
the loop. In system B, the listing is generated by the vendor and contains
price index information. Then it travels through an additional party (the
payment processor) before reaching S and then round tripping all the
back. Then the vendor, implicitly trusts both parties will do their job
properly, again, because a human can't be in the loop.The end result for the vendor is the same; but system A is more efficient,
requires less trust, and because of reduced complexity, is less error
prone. System A also allows for standards regarding the protocol used for
communicating with price indexes to evolve independently of payment
processors. Furthermore, it doesn't require that price indexing information
appear in listings.Now, from what I can tell, there may be some variant ideas for system B
that have floated around during this discussion. There has also been
discussion about caching that could be performed by payment processors to
reduce their need to call out to price indexing services. Of course, never
having to do that at all is more efficient both in real time and in
implementation complexity -- so we ought to be discussing the need for
payment processors to be involved in the loop at all if the end result is
going to be the same. The main advantage to that approach that I've seen
thus far is that a vendor can go to a single place to configure both their
payment preferences and their price index choices. However, that seems to
me to be a value-add service that payment processors could easily provide
on their own -- and likely would if they were being used in an area that
required price indexing to begin with. That approach, though, doesn't
impose an unnecessary implementation burden upon payment processors
that do not need to deal with these issues.There has been much more said in this thread since my last response, so
I'll have to catch up when I can, but the above jumped out at me as the
crux of the issue, at least for me.�
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-29215926
.
Referring to my current re-statement of A (I should have called it A.b, and
we'll say @dlongley's original was A.a), some further comments:
- All that must get sent to the payment processor is the digitally signed
price in the chosen currency (i.e. no index info is relevant to the
payments processing function - It's still worth asking if the index info should travel with the price,
just for information purposes. (Which system generates the transaction
record? The Payment Processor or the Vendor's software? - RE: "price indexing could be used in a way that doesn't require payment
processors to be directly involved" << I think this is where A.b still has
us - RE: "This doesn't preclude standardizing a price index service protocol
either. It just doesn't have to be something that payment processors must
understand." << Also I think this is where A.b has us. - RE: "We could put out an additional spec in the Web Payments WG that
specifies how to talk to price indexing services in a standard way so that
vendors can do that before generating their listings if they want to."
My question (and worry, ...maybe unfounded?) is whether there can a home in
a Web Payments WG spec covering each of the steps in A.b. The payments
processor in the browser under scenario variant A.b has no use for price
index data. That's fine. But then can the Web Payments WG spec describe
some generic requirements for suppliers of "standard compliant" web
payments software that Vendors would run? Or is that space out of scope or
too controversial to get passed?
Perhaps if:
- The language for the requirement within the Vendors software just refers
to the need for "a price index" (and the documentation explains: "e.g. an
exchange rate, or some other baseline");
And assuming that many/most Vendor software will be supplied to Vendors,
and will not be home-grown by them:
- The standard would specify that a standard-compliant Vendor solution must
respect
(a) unrestricted vendor choice in currency for pricing and transactions;
(b) unrestricted vendor choice in pricing method (e.g. choice of price
index); and
(c) unrestricted purchaser choice to pay in any of the currencies that a
vendor is willing to receive.
Joseph Potvin
http://goo.gl/Ssp56
Your description of system A is pretty good. I think it's worth mentioning that there's yet another approach to this problem -- which is to allow the customer to pick a pricing index (from a Payment Processor that has such a value-add feature) that will convert whatever currency they want to pay in to whatever currency the vendor prefers. With this approach, the vendor could just create a single listing with the price and currency they will accept (they can still create multiple listings and currencies if they really want to) and then simply expect the customer to provide them with the correct amount and type of funds. In this case, the vendor doesn't have to do any work trying to figure out what they ought to accept and the customer gets to choose how their funds will be converted.
The vendor can, of course, always provide multiple currency options anyway -- should they fear certain options are too rare (or for whatever reason). With the current design (system A), both of these approaches can be employed and neither side needs to know about how funds were converted (or if they even were), they just get whatever they ask for independently of one another. Payment processors may elect to add services that support these kinds of features to attract more users, but they are not required to in order to be compliant.
It's still worth asking if the index info should travel with the price,
just for information purposes. (Which system generates the transaction
record? The Payment Processor or the Vendor's software?
It would be fine to include the index info with the listing (as purely informational). The transaction record is a combination of the listing the vendor creates and additional information generated by the Payment Processor.
My question (and worry, ...maybe unfounded?) is whether there can a home in
a Web Payments WG spec covering each of the steps in A.b. The payments
processor in the browser under scenario variant A.b has no use for price
index data. That's fine. But then can the Web Payments WG spec describe
some generic requirements for suppliers of "standard compliant" web
payments software that Vendors would run? Or is that space out of scope or
too controversial to get passed?
There are a number of different things that the charter for a Web Payments WG could cover. The charter certainly doesn't have to be limited to the very core e-commerce protocol. We are already looking at trying to include various aspects of online identity as well. It will ultimately be decided when the group gets chartered, but there's nothing that says we can't see if there's enough interest to attempt to put out a spec covering this sort of thing. These things can also always be addressed incrementally.
Two wording changes to eliminate ambiguity
RE: [Joseph Potvin]: Q6 suggested to refine but generalize the examples of indices https://web-payments.org/minutes/2014-01-15/
I'd like to ask if anyone has either objections or better suggestions to the following two proposed adjustments to "pricing index" and "indexed pricing".
Objective: Our intention is to enable vendors to post prices that automatically change with some external variable. The simple example given in the current work items survey is a bakery that may want to default their prices to automatically vary with, say, an index produced by their industry association that reflects input costs. This would save the vendor from having to login and manually adjust every single item's price each time they need to respond to the factors that affect their overall price levels. The proposed web payments structure would accommodate the capability for a sort of pricing autopilot for (a) businesses whose posted prices are typically dynamic, not static; or (b) businesses selling in more than one currency who may want to automatically anchor their relative prices to something more stable than volatile spot exchange rates without the costs and complications of forex hedging instruments. ... There are many use cases. The point being, the pricing method needs to remain vendor-determined, and we shouldn't assume that the default is a set of static posted prices.
Problem: The terminology "pricing index" and "indexed pricing" has been used so far, but it is too easy to confuse with "price index" as in the "consumer price index" (CPI), which is conceptually related in some circumstances, but is not functionally what we're referring to. Also that one concept it is not reflective of the very diverse set of potential reasons vendors might want to default their prices to automatically vary with some chosen external index. Furthermore, the limitation to "price" doesn't notionally accommodate barter, which the web payments system would do.
Solution: We can change:
- [from "price" to "value"] and [from "pricing" to "valuation"]
- [from "index" to "benchmark"] and [from "indexing" to "benchmarking"]
The "benchmarking" language is widely established. Examples:
http://www.alsbridge.com/methodology/benchmarking/index.html?utm_campaign=PR-2013-1001-state-of-price-benchmarking
http://www.outsourcingleadership.com/knowledgebase/whitepapers/2013-price-benchmarking?utm_campaign=PR-2013-1001-state-of-price-benchmarking
http://www.citifx.com/electronic-solutions/citifx-benchmark.html
https://www.cibcnotes.com/ScreensCA/CAN_CIBCIndicesIntroduction.aspx
http://www.wilmingtontrust.com/wtcom/index.jsp?fileid=3000200
So, after the current voting on the Charter I'd propose that the particular line about this item could change from:
"Methods to accommodate transaction currency choice and single-currency/multi-currency price management in association with listings"
To:
"Methods to accommodate transaction currency choice as well as value management benchmarks for listings"
BTW, the word originates from land surveying. A "fundamental bench mark" is a horizontal line chiseled into rock or in concrete on rock into which an angle-iron can be set to form a “bench” for leveling equipment.
Please advise if you disagree with this change, and if so, what terminology would you recommend?