Most merchant accounts can process credit cards for customers in any country as long as all amounts are in the merchants native amount. For example a US merchant can accept an order on their website from a customer in Europe. In this case the order total would be in USD and the batch would be sent to the bank in USD. The customers card would handle the conversion to Euros and the customer would see the order amount in Euros on their credit card statement. While this process works, it is not very clean for the customers.
Merchants looking to implement a more localized experience for their customer will need to implement multicurrency processing. The end result will be a separate set of prices for the end customer. Customers in Europe for example would be directed to a website where all prices are listed in Euros. During the entire order process all amounts will also be in Euros. Perhaps most importantly, the order total on their receipt should match the amount on their credit card statement.
Multicurrency processing also provides an enhanced interface in the merchant console. The batch manager will list both the customers currency and the amount converted to the merchants currency.
Currently multicurrency processing requires the use of two merchant accounts. One for domestic transactions and one for international transactions. Merchants should contact their merchant service provider for pricing and account signup. In the merchant console one user name can be connected to both accounts but when integrating two separate source keys. The application (shopping cart) must store both source keys and use the correct one based on whether the order is in domestic currency or international. When sending transactions on the domestic source key no extra fields are required. The merchants currency will always be used.
When processing an international transaction, the second non-domestic source key will be used. An extra field 'currency' is required. This field indicates currency of the transaction. The currency field must be set to the numerical code of the currency. The list of codes and be found here: Currency Codes. The 'amount' field would then contain the amount in the specified currency. When the gateway responds it will contain three extra fields: the merchants currency code (typically 840 for US Dollars), the transaction amount converted to the merchants currency and the conversion rate used.
For multicurrency processing to work the prices listed on the site must already be converted to the targeted currency. Unfortunately the rates are constantly changing. If you are maintaining your site with four different currencies that means updating four sets of currency. Fortunately the system provides an automated method for looking up the current rates and doing currency conversions. This functionality would be implemented would be implemented with either the DotNet api or the SOAP interface.
