Support multiple simultaneous currencies and price algorithms

[msporny]

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

[dlongley]

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.

[jpotvin]

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.

[dlongley]

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.

[jpotvin]

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.

http://www.projectmanagementhotel.com/attachments/6017/ClassDiagram_WebPayment_ChoiceOfCurrencies_PriceIndicesPDF_4nov2013.pdf

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/web-payments/payswarm.com/issues/9#issuecomment-27724951 .

http://goo.gl/Ssp56

[dlongley]

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.

[jpotvin]

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/web-payments/payswarm.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

[dlongley]

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.

[jpotvin]

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

[msporny]

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.

[jpotvin]

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

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

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:

1. 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
2. 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.

[dlongley]

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.

[jpotvin]

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:

1. 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?
2. 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/web-payments/payswarm.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

[dlongley]

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

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

[jpotvin]

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

[msporny]

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

[jpotvin]

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

http://goo.gl/Ssp56

[jpotvin]

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

[dlongley]

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:

1. Vendor configures their software to use an independent price index service S to use to obtain listing prices.
2. Vendor creates a new listing; their software uses S to obtain the price and then digitally-signs and stores the listing.
3. Vendor's software displays the listing on the vendor's site.
4. If a customer decides to purchase, they give the digitally-signed listing to their own payment processor and the purchase occurs.

In system B:

1. Vendor creates a new listing that contains a link to an independent price index service S.
2. Vendor's software sends the listing to the vendor's payment processor.
3. Vendor's payment processor uses S to obtain the price for the listing, rewrites it, then sends it back to the vendor's software.
4. Vendor's software digitally-signs and stores the listing.
5. Vendor's software displays the listing on the vendor's site.
6. 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.

[dlongley]

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.

[dlongley]

@msporny,

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.

[jpotvin]

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

http://goo.gl/Ssp56

[jpotvin]

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:

1. Vendor configures their software to use an independent price index service S to use to obtain listing prices.
2. Vendor creates a new listing; their software uses S to obtain the price and then digitally-signs and stores the listing.
3. Vendor's software displays the listing on the vendor's site.
4. 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:

1. Vendor creates a new listing that contains a link to an independent price index service S.
2. Vendor's software sends the listing to the vendor's payment processor.
3. Vendor's payment processor uses S to obtain the price for the listing, rewrites it, then sends it back to the vendor's software.
4. Vendor's software digitally-signs and stores the listing.
5. Vendor's software displays the listing on the vendor's site.
6. 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/web-payments/payswarm.com/issues/9#issuecomment-29215926 .

http://goo.gl/Ssp56

[jpotvin]

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

[dlongley]

@jpotvin,

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.

[jpotvin]

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:

1. [from "price" to "value"] and [from "pricing" to "valuation"]
2. [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?