Currency in Magento
Magento is built to be an extensible multi-lingual, multi-currency, and multi-national platform. It’s flexibility can create significant challenges for merchants and developers alike. This has led me to dig deep into the currency systems that are built into the pricing and sales portions of Magento.
At a basic level, native Magento currency options can be expressed as three possibilities. The first option is to simply have your base price set on every product using a single currency. This base price is the one that you set when you are setting the price value on a product at the default level.
The second option is to use Magento’s native currency conversion that operates at runtime on a per store basis. As a Magento merchant or developer, you have the option of allowing your customers to view prices in a different currency from the one in which they will be charged. This conversion is merely for evaluation purposes since the customer will still be charged in the base currency but they will at least get an idea of the approximate amount they will be charged after conversion. These conversion rates can be pulled from a conversion rate service or entered manually in the admin. If the rates are pulled from the external service, they can be set to automatically update daily. This type of conversion is often sufficient for merchants who do the majority of their business within one country and merely have the option of other currencies for those few countries that make up a minority of their sales.
For those who are targeting a larger percentage of sales in more than one country, Magento has a third option. A merchant can set a different currency at the website level from the one set at the default level. This allows the merchant to do everything from setting prices that are specifically formed to look good in that currency to charging the customer’s credit card in their native currency. This third option is the most time consuming and labor intensive of all of the currency options, but it also has the greatest potential benefit.
Using the Same Base Currency and Display Currency
Anyone who has worked extensively with prices in Magento knows that there are quite a few ways to modify those prices. Within native Magento Community Edition, you are required to set a price on a product at the default level. You also have the option to set a website specific price. Each of the following elements also have options to set pricing at default or website levels, in addition to adding other more specific limitations upon who receives the price as implied by their names:
- special pricing
- customer group pricing
- tiered pricing
- catalog price rules
- shopping cart price rules
All of these will be combined, along with any other pricing modifications that might come into play, to form the product’s final price. This final price is the total price of the product itself and excludes things like shipping, tax, and certain discounts which are applied to the entire order.
Both the base price and the display (converted) price are stored on the cart and both are transferred to the order at checkout. When the only allowed display currency is also the base currency, the base price is always the same as the display price. Both of these prices are then used throughout the life of the order. The display price is primarily used for display to the customer, and in certain places in the admin, while the base price is used primarily for calculations.
Differences when using Currency Conversion
When Magento is set to use a conversion rate other than 1 (which produces no conversion) it converts the base price to the display price before performing any other calculations. All other calculations are then simultaneously performed, using identical operations, on both the base price and the converted display price to arrive at the final totals for each price.
It is important to understand that, depending on the situation, the final display price total may differ by a cent or more from the value that would be generated by taking the final base price total and converting it. How much the values differ depends on the number of line items included in the calculation – though it should never be more than a few cents.
When a customer places an order, they will be charged the calculated base price total converted, by the payment processor, into the customer’s currency. Since this is not the way that the display price total is calculated, the display price total will only give the customer a close approximation of what the charge will be in their currency. It will not be an exact representation of actual charges.
Impact of using Multiple Base Currencies
Using multiple base currencies may seem confusing at first and it does require that the person who imports products is thorough. Because of this, I recommend that you have a strategy in place for implementing products with multiple base currencies before publishing them to a live production environment.
To understand the importance of being thorough in a situation where you have multiple base currencies, consider a scenario where a US run company has a large customer base in Europe and the UK. The merchant has already imported their entire product set that is offered across all of their stores. This merchants opens their European and UK websites with Euros and GBP as the websites’ respective base currencies. The merchant also has general shopping cart price rules set up for all websites giving customers 10 off Product A when purchased with Product B and 5 off Product C when it is in a cart where the cart totals 100 or more.
Some interesting things happen when you create websites with different base currencies to include these products. When a customer browses to the new website, he/she will find that the price has the same numerical value on the two new websites as on the US website. The product that is $100 on the US website will be €100 and £100 respectively on the European and UK websites. This is obviously not accurate, and will happen whether or not you have currency conversion rates set up.
If each website has a different base currency, each website should have a different base price to go along with that currency. This different base price could be set by either having a separate product that is exclusive to each website or by having a product in multiple websites with a different website level price for each website.
By extension, the shopping cart price rules which were originally made for a scenario involving only dollars should either be split into multiple shopping cart price rules, converted into percentage based rules, or accepted as different value rules on each website. Some of these rules may still be logically similar, for instance, the rule that gives $5 off Product C when it is in a cart where the order totals $100 would be a valid although although slightly more expensive rule when it was offering €5 off a €100 cart.
The most important thing to realize with using different base currencies is that you cannot simply assume that all of your configured prices and rules will work as expected, but instead, each area of the admin where a price is entered must be evaluated for consistency with the new multiple base price structure.
While Magento has a few ways to deal with currency conversion, it is important to consider the implications of each of the factors for your customers when they are paying in a currency that is not your Magento Installation’s default base currency. There are other possible pieces to this puzzle that can come into play if native Magento alone does not suit your needs.
One possible option is to use PayPal Express as the only or primary payment method on websites that default to a display price other than the base price they will be charged. PayPal will show the user what they will be charged in their currency according to its conversion rates. This can protect your users from potentially having to pay credit card surcharges when they pay in a non-local currency.
Another option is to use a third party or custom solution that uses multiple base currencies. Classy Llama has built a currency conversion automator which allows the merchant to have the increased functionality and usability that comes with using multiple base currencies with a lot of the convenience of using multiple display currencies. This extension allows the merchant to enter a default price for a product and 1 or more website level prices. It then uses a set of rules and order of priority to convert one of the manually set currencies to each of the other website’s prices using the conversion rates set in the admin. The extension then round the price to make prices look consistent across the entire site.
For example, a product with only a default price of $10.00 where the system used USD as its default base currency, would have its base price on the UK website that used GBP as its base currency calculated by taking $10.00 times the conversion rate from USD to GBP and rounded to the nearest pound. So assuming that the conversion rate was $1.85 to £1 the product would have a UK website level price of £19.00 which is the converted price of £18.50 rounded to the nearest pound.
This type of solution obviously has certain limitations. For instance, shopping cart price rules are unaffected by this extension and tiered prices and customer group specific pricing likely would have used their own native currency selection options, but it is an example of how a combination of the manual and yet more precise and flexible nature of using multiple base currencies could be combined with the simple and automated nature of display price currency conversion.
As merchants and developers consider how to handle multiple currencies, it is important to consider the implications of each currency option. The merchant may choose to ignore currency conversion altogether, use currency conversion with display prices, or introduce multiple base currencies and accept the extra overhead incurred. The effort involved in using multiple base currencies is likely only necessary or beneficial to merchants who do not do the majority of their business in a single currency or who have separate distinct web presences for countries whose native currency is different from that of the merchant.
The use of multiple currencies on a website should not be considered lightly, but should be approached from a strategic perspective that will allow for long term maintenance of the solution while still providing sufficient functionality to the merchant and customer alike.
Posted on January 15, 2014
Posted by Jonathan Hodges