developer:multicurrency

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
developer:multicurrency [2010/09/09 14:31]
vladg double text
developer:multicurrency [2011/08/03 15:25]
kahlei
Line 1: Line 1:
-====== ​Multi-Currency Processing ​======+Multi-Currency Processing
  
-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.+Most merchant accounts can process credit cards for customers in any countryas long as all of the amounts are in the merchant’s ​native ​currency. For examplea US merchant can accept an order on their website from a customer in Europe. In this casethe  ​purchase amount ​would be in USD and the batch would be sent to the bank in USD. The customer’s purchase ​would be converted ​to Euros by Visa or MasterCard ​and the customer’s European issuing bank. The customer would see the converted purchase ​amount in Euros only on their credit card statement.  ​This amount will not match the purchase amount that the customer viewed in USD.  In addition to the purchase amount in Euros, they will see a line item representing the conversion cost. While this process works, it is not very clean or clear for the customers. The fact that the USD purchase amount, Euro purchase amount and conversion cost are all different amounts that the customer may or may not recognize, this results in the escalation of chargebacks.
  
-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. ​ +Merchants looking to implement a more localized experience for their customers ​will need to implement ​multi-currency ​processing. ​With this type of processing, ​the end result that the customer ​sees on their credit card statement is the exact cost of the product or service at the time of purchase. Customers in Europe for examplewould be directed to a website where all prices are listed in Euros, rather than in USD. During the entire ​purchasing ​process all of the amounts ​viewable to the customer ​will also be in Euros. Perhaps most importantly,​ the purchase ​total on the checkout page will match the amount ​that will appear ​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.+Multi-currency ​processing also provides an enhanced interface in the merchant console. The batch manager will list both the customer’s ​currency and the amount converted to the merchant’s ​currency.  
 +Currently, multi-currency processing requires the use of two merchant accounts; one for the processing of domestic transactions and a second for the processing of 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 are required. The application (shopping cart) must store both source keys and use the correct one based on whether the transaction is a domestic transaction or in an international currency. When sending transactions on the domestic source key, no extra fields are required. The merchant’s currency will always be utilized
  
-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 cartmust store both source keys and use the correct one based on whether ​the order is in domestic ​currency or internationalWhen sending transactions on the domestic source key no extra fields ​are requiredThe merchants currency will always ​be used.+When processing ​an international transaction, ​the second non-domestic ​source key would be utilizedAn extra field entitled '​currency'​ is requiredThis field indicates ​the currency of that particular transaction. The currency field must be set to the specific numerical code that is assigned to that currency. The list of codes can be found here: [[Developer:​currencycode|Currency Codes]]. The field entitled ‘amount’ would then contain the purchase amount in the specified currency, not in USD. When the gateway responds it will contain the following three extra fields: the customer’s currency code (typically 840 for US Dollars); the transaction amount converted to the customer’s currency; ​andthe conversion rate used.  
 + 
 +For multi-currency processing to work, the prices listed ​on the merchant’s website must already be converted to the targeted country’s ​currency. Although conversion rates are constantly fluctuating up or down .01 to .03 of a percent, multi-currency processing ​ provides an automated method for updating these currency conversions daily, ​no matter how many different currencies ​are loaded on a particular websiteThis functionality would be implemented with either the DotNet api or the SOAP interface
  
-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: [[Developer:​currencycode|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 with either the DotNet api  or the SOAP interface. 
developer/multicurrency.txt · Last modified: 2011/08/03 15:25 by kahlei

Page Tools