Given the Prohibition on Intraregional Transactions by the regulatory bodies (click here for more on that), merchants should ensure that they correctly route domestic customers to pay in their local currency. To do so, there are a few approaches that are used. This article will go over the potential problems with each approach and provide our recommendations to solve this problem.


MethodDownfalls/ProblemsReliability
IP Location
  • The customer may be out of the country or using a VPN while making a domestic payment. (E.g. SA Cardholder making a payment to an SA merchant while in Germany)
  • This would potentially lead to foreign customers paying in the local currency
Low
Billing Address Country
  • The customer may not differentiate between the Billing Address and Shipping Address.
  • A domestic cardholder may be living abroad and may incorrectly use their foreign address as the billing address

Med-High
Country/Currency Dropdown
  • Direct the customer to select their local country/currency via the information displayed to the customer prior to checkout.
  • The customer could miss/ignore the information
  • The customer could misunderstand or choose the country based on their current location
Med-High




We recommend using a combination of the three approaches, use IP Location to select the default country for each customer, then direct them to a Country/Currency dropdown selection field which should always be present and visible. Accompany this with help text that appears when they first land on the website indicating that they (the customer) should select their home country to see prices displayed in their home/local currency.


Then during the signup or checkout process, prompt the customer to enter their Billing Address as the address which is registered with their bank. If the customer selects the merchant's country* but had previously set their country/currency to something else, add logic to change the currency to the merchant and the customer's local currency. It is also recommended to include a clear notice that the currency was changed automatically due to regulatory requirements or the merchant's preferred wording on the topic.


*Make sure to provide a Country and Province/State dropdown list that in the backend maps to the respective country code as per the ISO 3166-2 standard.


Finally, add logic to catch the domestic customers that were able to get past the other measures.


Example Scenario: SA Customer paying via a SA Merchant where the customer selected a foreign currency and also entered a foreign Billing Address then proceeded to attempt a payment via a foreign currency.


In this scenario, the payment should be declined with one of the following Result/Return codes:

  • 800.100.173    transaction declined (invalid currency, not processed by authorization center)
  • 600.200.500    Invalid payment data. You are not configured for this currency or sub type (country or brand)


Add logic based on the payment response returned following the failed payment to reroute and advise the customer to re-attempt their payment in the merchant's local currency (in the above scenario, this would be ZAR). The customer is then expected to retry the payment and should be able to complete the payment process successfully.


Using the full approach outlined above should greatly reduce the chances of a customer attempting an Intraregional Transaction and facing the frustration of their payment failing. Which would in turn reduce the need to assist the customer from the merchant's side.


Kindly note that currency conversions must be managed on the merchant's site via their own custom or via an existing plugin or library.


If you have any questions or require further guidance, please create a ticket via this Helpdesk or send an email to [email protected]