Hmm... that select was taken out because of other conflicts. I can't decide if the currency setting should be handled by the payment gateway or Ubercart itself. One reason is that the payment gateways accept different currencies and sometimes use non-standard formats. However, if it were at the store level, I wonder if it should just be a text box where folks make sure to put in a valid currency code.

Ideas?

Yes, one problem is that of converting between currency formats, I suppose; but if you stick to ISO 4217 then the payment gateways can provide their own translation table if necessary. But it'll have to be a store-wide setting, I think. I mean, unless you want to go down the route of multiple currencies, which IMO would be a rather unnecessary abstraction layer at this stage (maybe for v3, eh?!).

How about a select box giving all the possible ISO 4217 currencies (with a simple in_array() validation routine), so payment gateways can rely on this. (IMO this should then generate a UTF-8 currency symbol, although users should be able to configure whether to display it before or after the amount.)

To look at the alternative to having a store-wide currency setting, that of giving payment gateways a certain autonomy, is that this would create a potential situation where stores could be listing prices in one currency and charging the customer in another. There is no situation in which a payment gateway should charge in any other currency than the listed prices unless doing an exchange rate conversion; but this would then require that the payment gateway is aware of the listed store currency so it knows what to convert *from* -- which then requires a default store currency.

Re: currency conversion. This is just an idea, but if customers want to be charged in another currency then someone could write a module to allow the store owner to set up in advance a number of alternate currencies (which would depend on what their cc merchant service allows them to charge), and this could handle the exchange rate, etc., by using hooks to change the displayed prices in the store and at checkout without needing to change anything in the database. This requires, however, that payment gateways are written to expect the currency code given in uc_order_load() to be in the ISO format, so in my view this should be standardised in Ubercart v1 (and modules should probably indicate their compatibility with the standards in Ubercart v1 in roughly the same way that Drupal modules indicate their compatibility with versions of Drupal; that way you can change things later and people will know what modules interact nicely with your different versions).

Thank you for your time and thoughtful response.

I agree with you that we should use the ISO format, and your reasons for keeping a store-wide default have convinced me. In terms of implementation, though, I'd like to offer the following for now...

Keep the currency code as a textfield that defaults to USD and can be changed to any other code, but validate it against an array of possible currency codes. I've heard it said on usability pages that in a situation like this it's faster for someone to just put in their own currency code instead of find it through a massive select list. How does this proposal sound? I suppose in the end it isn't much more code to construct a select list, and it may even be less since the Forms API will take care of the validation itself... Thoughts?

By removing the names of the currency and the select list from RC 4, we did away with 200 lines of code and about as many translatable strings.

I also like your thoughts related to a possible roadmap for currency conversion.

Thanks again!

Thanks for your reply. Now that you put it like that, yes there are way too many for a select list! I don't know what I was thinking...

I suppose one could simply have a little popup to explain it, like your cvv_info popup, with a link to the official iso.org list. And I agree all that's necessary, really, is just an ordinary form validation.

Just below that we can imagine where the "other accepted currencies" field can one day go

hehe Dreaming is good. I seriously fall asleep imagining ways to improve the core APIs...

I would like to see this setting back as well, so I have put together a first attempt at a solution. It includes validation against a list of the all the currency codes. Ideally this list should be updated from the ISO website somehow, but other than scraping the page, I don't see an easy way to do it. So, for now, its just a static array. The patch is against v1.0.

One thing I would like to change is the capitalization check. Its kinda late, and I can't figure how to uppercase the entered value before saving it. Hence, the validation currently fails if its not all in uppercase. Not a big deal, I guess, but its not very elegant.

Thanks for taking the time to put that together. I actually didn't remember about this thread but elsewhere posted that we added the setting back in. It'll be in the 1.1 release. What we didn't do was include any validation on the field, though I'll take that into consideration. I was inclined just to leave it up to folks not to screw up their own currency. (Well, and not risk keeping anyone from setting it to a legit currency code that we didn't know about.)

Ya, after I posted this, I spoke with a developer I'm working with, and he mentioned it was actually already done too. So I guess I wasted a bit of time, but it was good practice. And you have a validation routine if you want it, but I understand your reasons for not using it. I guess someone who has rights to set the currency, should know what they are doing, eh?

Anyway, glad to hear the option is back, as we need it for our multi-currency setup. The developer will be letting you guys know more about that shortly.

Sounds intriguing.