We can't ascertain if this is a bug in Commerce Multi Currency (see: http://drupal.org/node/1932598) or the Commerce Auht.net module.

Issue is that converted currency amounts are being sent to Authorize.net as USD. Huge problem.

Example - selected currency is GBP.

Total at checkout displays as £100.00 GBP.

Amount sent to Authorize.net is $100 USD. Eeek! This should be approx $160.

Same if we switch to Euros (Euro value is sent to A.net as USD).

Comments

dwkitchen’s picture

dwkitchen commented
Status: Active » Fixed

In fact no currency code was being sent to Authorize.net, this meant that Authorize.net will use its default currency. This would be fine in most cases where merchants only operate in one currency.

This is now fixed in Git and will be in the next release.

jasonabc’s picture

jasonabc commented

Thanks - this is not an issue with the currency Authorize.net process in though? They will only process in one currency (according to them - this is set when the account is created and cannot be changed). Our gateway is set to USD.

The issue is that the *displayed* currency value the user sees is mistakenly being sent to A.net - who then process it as USD.

100 Euros -> 100 USD

This should be

100 Euros -> 160 USD

dwkitchen’s picture

dwkitchen commented

It seems there were two issues, Authorize.net does support multi currency, however that depends on your payment processor supporting it as well. In the A.net support for AIM they say that with Streamline (subject to your account with them) they can support GBP, EUR and USD.

It is possible to you multiple currencies without the Commerce Multi Currency module and this now works. I think this was the case for you as well, i.e. all that was being posted was 100, without the currency. I think what will happen if you try the dev version now is it will post 100 GBP but not 160 USD.

If I understand correctly you only want to present the prices in GBP, but still process to transaction in USD? If this is the case then I think the issue lies with Multi Currency.

das-peter’s picture

das-peter commented

@dwkitchen: Please have a look into this proposal for a payment gateway guideline: http://www.drupalcommerce.org/discussions/7670/design-pattern-payment-ga...
I created this because the Commerce Multi Currency or other modules have no way to be "payment" aware with the current architecture. Thus it's the job of the payment gateway to "validate" the input, what makes sense because the payment gateway should know exactly what it accepts.

dwkitchen’s picture

dwkitchen commented

I have replied to your comment on drupalcommerce.org and disagree. Payment gateway module should not do any form of currency conversion.

jasonabc’s picture

jasonabc commented

@dwkitchen: "I think what will happen if you try the dev version now is it will post 100 GBP but not 160 USD. "
--- This is no good. This is a US based store so it needs to send values to Authorize.net as USD regardless of the currency selected by the user.

"If I understand correctly you only want to present the prices in GBP, but still process to transaction in USD?"
--- CORRECT. Not just GBP though - any currency.

I agree that the payment gateway module should not do any form of currency conversion. But the issue here is NOT Authorize.net's handling of different currencies.

There are two use cases for our store:

1) Prices entered in USD by Admin in the backend.
2) Prices that are "displayed" by the Multi Currency module on the front end.

The prices in #1 should be the ones sent to Authorize.net. The prices in #2 should just be a display thing, but this is not the case. The displayed/converted prices are the ones being sent to Authorize.net which in turn process these as USD. This is a major bug.

This would seem to point to a problem with the Multi Currency module.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

spiderman’s picture

spiderman
he/they
Primary language English
Location Halifax, NS
commented
Status: Closed (fixed) » Active

Unfortunately, this "fix" seems to have broken the simple case where our single-currency (CAD) store displays prices in Canadian, but our Authorize.net account is set to USD since they've told us our account can only handle one currency at a time. Thus, this commit which adds the currency code explicitly seems to have broken our store, since it is now explicitly asking Authorize.net to process in CAD, which it will not do.

I'm not sure what the proper fix for this is, but it doesn't seem like we can resolve it through Authorize.net, so it'd be nice if we could deal with it in the module somehow- in the meantime, we've rolled back to 1.0-rc1, which is not sustainable.

Anyone have ideas on this? I'm happy to help with rolling up a patch if we can come up with a reasonable approach..

jasonabc’s picture

jasonabc commented

To add to this - Authorize.net are quite clear that they can process transactions in most major currencies *but this has to be set when the account is set up and cannot be changed*.

If you request to process in EUR- then your account can only process in EUR and nothing else.

Converted currencies on the site should just be a display thing for customers. The actual amount sent to Authorize.net should be the total of the values entered into the backend in the default currency Drupal Commerce and Authorize.net are set to - NOT the converted amount the customer sees.

dwkitchen’s picture

dwkitchen commented
Status: Active » Closed (fixed)

spiderman, if you are sending prices form you Canadian store to a USD Authorize.net account then you are not processing the correct value for the transaction. Authorize.net will support multi currency, but in the mean time if you want to charge the customer in CAD then you need a second Authorize.net account in CAD.

spiderman’s picture

spiderman
he/they
Primary language English
Location Halifax, NS
commented

@dwkitchen: yes, I think you're right. Digging into this more on the Authorize.net side, it seems that we originally had an account which assumed USD, but is actually charging CAD- when the module was not sending any explicit currency code, the gateway assumed it was USD, charged in CAD, and all was well.

Now that it sends a code, there's a mismatch- but until today I was given to understand there was no way to correct this at Authorize.net's end. Having gone through a bit of a maze, we determined that it's possible to setup a second gateway account in CAD, which we'll send these transactions through in future- in short, our account was setup in a bizarre, legacy kind of way.

Finally, I'll note that we discovered a workaround in our case (until we have the proper CAD gateway setup) which is to disable all currencies but USD, and update our products to be in USD, at which point they display with no currency explicitly mentioned to the user, and the transaction goes through as before, since the currency code matches what our USD Authorize.net account expects.

Anyway, thanks for the clarifications :)