Inconsistencies in amounts sent to payment gateways

Could you explain how this module handles passing amounts to payment?

This module doesn't pass a thing at all.

It implements hook_commerce_currency_info_alter() to set conversion rates.
It implements hook_commerce_price_field_calculation_options and commerce_multicurrency_commerce_price_field_formatter_prepare_view to add currency conversion support to custom price fields.
Everything else uses rules, which basically means default commerce behavior.
I can only guess that if a payment gateway fails it will also do so if you us e.g. GB as default store currency or somehow it isn't currency aware.

So should the current module affect only display of prices or also affect the amount used for payment?

By default the module registers a handler for the rules event commerce_product_calculate_sell_price and with release 1.3 one for commerce_shipping_calculate_rate, if the shipping module is enabled, as well.
So whatever uses the sell price or a shipping rate is affected.

I guess the payment modules should use the sell price to deal with, but I don't know it for sure.

typo

Unlikely, because:

I guess the payment modules should use the sell price to deal with, but I don't know it for sure.

We are getting this as well. 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). Not sure if this is an issue with Multi-Currency or the Commerce Authorize.net module.

@jasonabc My earlier answer still is valid:

This module doesn't pass a thing at all.

It implements hook_commerce_currency_info_alter() to set conversion rates.
It implements hook_commerce_price_field_calculation_options and commerce_multicurrency_commerce_price_field_formatter_prepare_view to add currency conversion support to custom price fields.
Everything else uses rules, which basically means default commerce behavior.
I can only guess that if a payment gateway fails it will also do so if you us e.g. GB as default store currency or somehow it isn't currency aware.

So if there's an issue it's likely in the payment module you use. Please report the issue in the issue queue of the related payment module. If the maintainer of the module needs information or support I'm happy to help.

Thanks guys. I have opened an issue on the Authorize.net module issue queue. Surprised this hasn't come up before looking at the number of sites using multi currency and Authorize.net...

http://drupal.org/node/1960524

Thanks for creating the related issues - I follow all of those now, so I can provide support where necessary.

Currently it seems that with the current architecture the payment gateways can't assume that they get the amount in a supported currency. However they should always be able to use commerce_currency_conversion() to convert the given amount from the provided to a supported currency.
Payment gateways that support multiple currencies could / should allow to configure which currency has to be used (generally or for the case the provided currency isn't supported).

Added proposal for documentation of the pattern here: http://www.drupalcommerce.org/discussions/7670/design-pattern-payment-ga...

I have commented on the drupalcommerce.org, I summary a payment gateway module should never convert currencies.

Since the currency conversion is handled by the users credit card company at the time of the transaction, there is no need to send currencies to the gateway. The site should send whatever the default currency has been set to (in our case USD) - it should NOT send the currency selected by the user (this is just a display thing for customers)

So, if it may be illegal to send a default currency to a payment GW (e.g. default is EUR, but the user has selected USD), then payment modules should always send the currency the user has selected?

I guess it's illegal or at least not nice to send an amount / currency to the payment GW that wasn't displayed to the user.
I can't imagine that a law that says "You've to sent the amount / currency that was originally stored in your storage system".
This basically means the selection of the payment GW should be currency aware - so that the payment GW doesn't have to convert the amount / currency. That way you can ensure the amount displayed to the customer will be the exact amount that's charged or at least sent to the payment GW.
From this perspective it's even less related to this module.

It's more about if we have to implement a hook / callback to allow payment GWs to expose the supported currencies / precisions and automatically filter the available options by the user currency / the currency of the order (by the way, as far as I know it would be possible to mix multiple currencies in one order, so another case to deal with...).
For now it's up to the site builder to provide the appropriate payment GW options.
I'm not sure if this is already possible by using rules or a hook.

@marktheshark thanks for your thoughts.

The key point is, the order total presented to the user must be what the user is charged.

At the moment I would consider this module to work as designed, the price is changed to the selected currency and the order total is shown and stored in that currency. Payment gateway modules also work as designed, they take the order total, value and currency, and charge the payment method that amount (there was a bug in Auth.net that didn't do this).

This operation is very common in the UK where stores will offer the option to purchase in GBP and EUR and will have a merchant account and user a payment gateway that supports this. Sage Pay and Auth.net both being examples of payment gateways that support multiple merchant accounts with multiple currencies.

In Europe customers will know if they are better off paying in GBP or EUR depending on the exchange rate of their card compared to that being offered by the site.

In most cases the Payment Gateway module has no way of knowing what currencies it can accept unless the site bilder configures it somewhere. They way this would be done in the current Drupal Commerce payment framework would be to put a condition on the payment method rule to check the currency of the order total.

There is another option and that is to display to the user estimated prices in their local currency during the shopping experience, however when they reach the checkout stage prices return to being shown in the stores currency. I have done this before.

This seams to be what @jasonabc is after, but as mentioned above this means that on the checkout page they need to be returned to the stores default currency. Could this be implemented as a rule? When the user starts checkout the users currency is set back to the default currency.

There is another option and that is to display to the user estimated prices in their local currency during the shopping experience, however when they reach the checkout stage prices return to being shown in the stores currency. This seams to be what @jasonabc is after.

Absolutely not correct. Where have I said this in previous posts?

The bug that I raised in #6 needs addressing. If I select EUR then I see prices in EUR everywhere on the site - the product grid, the detail page, the cart and checkout. We have this working fine.

But if my total is 100 EUR - the "100" value is being sent to Authorize.net. Who take that 100 and process it as USD. This is a critical bug.

The displayed value is being sent to the gateway. This is not correct. The prices entered in the backend that use the default store currency should be sent to the gateway - not the displayed prices the customers see. Authorize.net cannot process multiple currencies. They told us the currency is set when you set up your Authorize.net account and that is the currency that funds are processed in.

Our gateway is set to USD. Our prices are entered in the backend as USD. The converted price users see is irrelevant to us, but it is this value that is being sent and this is a critical flaw.

Absolutely not correct. Where have I said this in previous posts?

#14

The site should send whatever the default currency has been set to (in our case USD) - it should NOT send the currency selected by the user (this is just a display thing for customers)

But if my total is 100 EUR - the "100" value is being sent to Authorize.net. Who take that 100 and process it as USD. This is a critical bug.

This was fixed in #1960524: Converted currencies sent to Authorize.net as USD, the amount sent to Authorize.net will now be 100 EUR.

The displayed value is being sent to the gateway. This is not correct. The prices entered in the backend that use the default store currency should be sent to the gateway - not the displayed prices the customers see.

No, the price the customer sees is the price the customer pays.

Authorize.net cannot process multiple currencies.

Yes is can. Visit http://developer.authorize.net/guides/AIM/wwhelp/wwhimpl/js/html/wwhelp.htm, and navigate to Introduction > Payment Processors > North American Payment Processors > Accepted Currencies. If you want to process transactions in EUR you will need to open a merchant account with one of the listed European Payment Processos and add the account ID to the Authorize.net Account.

You have two options:

• Sign up to a EUR merchant account and offer checkout in EUR; or
• only offer checkout in USD, but display guide conversion prices to customers.

@dwkitchen Thanks for responding to the posts!

I guess we should draw a flow chart, so people not familiar with the guts of Drupal Commerce have a chance to understand how the process works, too :)

Again, I don't see a bug in Drupal Commerce nor in Commerce Multicurrency - this seems to be caused by a lack of documentation.

I agree with marktheshark - currency conversions for display purposes only are extremely common on e-commerce sites. There is no reason why a customer needs to be charged exactly what they see as long as they are made aware that the transaction will take place in the original currency and that the converted price is for display purposes only. Currency plugins/modules for just about every other major e-commerce framework allow currency conversion for display only and transactions in the default currency - only Drupal Commerce seems to be missing this basic option. Most orgs do not want to allow transactions in multiple currencies because of the huge overhead in accounting, problematic reporting and the additional fees for multiple merchant accounts. In our case - a non-profit who has to report all donations back in USD against a USD project cost and share USD data with other apps/partners - it would be vastly preferable to have currency conversions for display only, especially since Multicurrency seems to have no facility for recording the exchange rate at the time of checkout. In fact, I was so sure this functionality would be available I've wasted quite a lot of time trying to figure out how to set it up using a module that obviously doesn't support it.

I challenge you to take a look at 10 mid-size e-commerce stores offering multi-currency NOT built with Drupal Commerce and test the prevalence of this approach yourselves. I would bet that more than 50% will use currency conversion for display only. It's practical for both users and site administrators.

@amberau79 - couldn't agree more with this.

@dwkitchen - a fundamental misunderstanding of the issues here. I talked to Authorize.net on the phone and yes they can process in many currencies BUT you have to choose what currency your account will be set up to process. If the gateway is set to process in EUR then that is all it can process. You cannot submit transactions in USD to an Authorize.net account set to process EUR, regardless of what your merchant processor can do.

Currency plugins/modules for just about every other major e-commerce framework allow currency conversion for display only and transactions in the default currency - only Drupal Commerce seems to be missing this basic option.

typo