The Payment API supports only one currency per site. While this is probably OK for most sites, there's still a need to support multiple currencies on the same site.

In general, the challenge is not collecting and using currency values. Because the Payment API functions as a reporting tool and tracks payments against goals, it's necessary to ensure that we can normalize the payments for these reports.

To support this, someone must write a new module.

This module must:

  • Live on its own project page (e.g. pay_currency)
  • When it is installed, do a variable_set('pay_currency_multiple', TRUE) (and remove said variable upon uninstall)
  • Store the exchange rate between a pay_form's currency and a related pay_transaction's currency at the time of that transaction
  • Provide views support and pay_form totals to accurately reflect these conversions

This module will probably:

  • Depend on the Currency module
  • Also support native conversions. For example, PayPal transactions return the currency conversion, which should probably be used rather than a wild guess through the currency API.
  • Require patches against pay.module itself - I'm open to that, assuming they're smart changes

Any takers? I'm usually available on IRC under the name 'vauxia'.

Please see #932666: Support for setting form and transaction currency values for the background discussion on this.

Comments

darrellduane’s picture

darrellduane commented

I am very interested in helping with this effort as I want to have the Pay module accept both US Dollars and Bitcoin. I will also need to write a new payment method for Bitcoin. I'll look for you on IRC. I go by either dduane or bitcoin_bonus there.

alan d.’s picture

alan d. commented

Sub.

I can have a look for an old version of currencies that I hacked for a custom mini-cart system that I wrote. I needed to have products added in a price, displayed in another and the payment was in a third!

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

We're looking to store exchange rates in Currency.module already. It would be cool it we could prevent duplicate efforts and have the maintainers of larger projects such as Pay and Commerce work together on a central Currency handling module.

Amateescu and I will be maintaining Currency. We'll be rewriting the module for version 2 and we'd really like input from people. One of the features we're currently having trouble with is how to display amounts in a certain currency in a certain locale. There seem to be a lot of differences in the world when it comes to that.

allie micka’s picture

allie micka
she/her
commented

Yay! Thanks for working on this, Xano!

My goals for the Payment API are, as best we can, to avoid depending on other modules for most of its functionality. Each payment form, and (I think) payment transaction, stores the currency code for that form/transaction. The amounts are assumed to be based on that item's currency.

My guess is that a healthy percentage of site owners (let's say 80%) only care about one currency, so doing it the way I've described will allow that 80% to choose their site-wide currency and not give it another moment's thought.

But my goal is to build modules that are loosely coupled, and I definitely don't want to create limits on people. That's why I've created this issue, which is a request for a module that allows the other 20% of Pay-using site owners to "upgrade" to a full-blown Currency system. The Pay module itself should (hopefully) not need to be changed for this to work.

This yet-unwritten pay_currency module will permit forms and transactions to have different currency codes than the site-wide currency default. I assume that it would do so by using your centralized Currency API because, why the heck wouldn't you?! So a pay_currency module would serve as the "glue" between pay and currency.

Your concern about localized formatting is sticky in this model, because at least part of that concern would be relevant to the 80% solution. I'm open to ideas!

I'm also not sure about how our summary values and views support would work, because aggregating totals in different currencies - without some kind of conversion - would get pretty strange-looking. I'm also open to ideas, and was hoping that the pay_currency author would have something to say about that :)

In either case, I'm definitely in support of a currency system that multiple payment systems can leverage. And I'd love to be, at least peripherally, part of the conversation.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Currency 7.x-2.x now contains pluggable currency conversion rates, price localization, and lots of helper code. It was designed to be unaware of how modules store their prices, so that's why it only provides conversion rates, and does not do the actual conversion, for instance. For an example of how to implement it, see Currency for Drupal Commerce.