05-13-2010 10:01 AM
Hi, my client is having issues with international cards being declined. I've been looking for documentation on this but have only found what follows. My main question is: "Is turning off G, U, and S going to do the trick as far as allowing all valid international orders to go through? Will doing so open up a huge fraud possibility or is the risk rather minimal?"
Does Authorize.Net support international transactions?
Yes. Merchants can submit transactions to the payment gateway on behalf of non-U.S. customers. To do so, the merchant's bank account must be with a financial institution located in the United States, and the merchant must be configured to accept the customer's card type: Visa, MasterCard, American Express, Discover, JCB, Diner's Club, or EnRoute. The payment gateway will submit the amount of the transaction to the customer's card issuer, who will then handle all currency conversion to U.S. dollars. Since default Address Verification Service (AVS) settings may cause foreign transactions to be declined, merchants who plan to regularly accept international transactions should make sure that their AVS settings are configured to meet their business needs.
I'm a bit confused about the last sentence, ie, how exactly should the AVS settings be configured to support international transactions?
From the Account Settings page, the recommended AVS settings are: B, E, R, G, U, S, N.
However, under "tips" it says:
"Not all banks outside the United States will return codes G, U and S. Therefore, these codes are not absolutely effective for preventing transactions from outside the United States."
This sounds as though G, U, and S are designed to PREVENT international transactions. (?)
I'd like to know what Authorize recommends for supporting international cards? If there's a doc somewhere that goes into detail let me know, but I couldn't find it.
Is turning off G, U, and S going to do the trick? Will doing so open up a huge fraud possibility or is the risk rather minimal?
05-13-2010 12:34 PM
AVS is only a moderately useful tool for detecting and preventing fraud. Positve responses do not mean an order is legit and negative responses do not mean a transaction is fraudulent. AVS should be considered with a variety of other factors when determining whether a transaction is possibley fraudulant and should be discarded and not the sole determining factor. Using AVS as the sole determining factor will result in legitimate sales being lost which is never a good thing.
05-13-2010 05:38 PM
I was hoping Authorize would have some detailed documentation about how to best support international transactions, even if just "recommendations" with caveats. For example, "here are recommended AVS settings to support international transactions". Or are merchants basically on their own as far as figuring this out?
05-14-2010 04:16 PM
Unchecking G, U, and S will generally allow international transactions to go through. This does mean that you won't be validating the address for transactions that return these codes. However, if these codes are returned, than address verification isn't possible anyway.
The G and S filters shouldn't affect domestic transactions, but that is ultimately outside of Authorize.Net's control and so we can't make a guarantee. The G filter is, by definition, only to be returned by non-US card issuing banks. The S filter indicates that AVS is not supported, but because card issuer rules in the US mandate that it is supported it should also never be returned.
The U filter is different, it essentially indicates that a bank does support AVS, but doesn't have an address on file. This is returned for some international transactions, but it is also returned for some domestic transactions. A common example is a prepaid card such as a Visa gift card. A customer using this type of card is likely not to have provided an address to the issuer when they purchased it.
05-26-2010 11:33 AM
I'm a bit confused by the information that is available for the x_currency_code parameter. Other posts on the forum say you can't do international payments, but this post (plus the FAQ and CP_guide.pdf) seems to say you can. I have a card-present test account and I see no place to set the AVS setting, or the merchant interface default currency that is also mentioned. Every transaction I submit comes back with error 39 and AVS code P.
So I'm assuming that (at least for card present) you can't submit a transaction with x_currency_code in anything but "USD". Why even list the parameter and currency codes in the implementation guide then? I've been telling international customers that (even though they need a US bank account) they would be able to charge in the supported currencies listed.
06-02-2010 10:50 AM
Hopefully I can clarify a little here. First off, you can accept payments through Authorize.Net from non-U.S. customers as long as your bank account is with a financial institution in the United States. You cannot, however, process in anything other than U.S. dollars. If you accept a payment from a non-U.S. customer, and your bank is in the U.S., then your customer's bank will handle the conversion from the customer's currency to dollars. That part in the CP guide that lists currency codes is outdated and I've submitted a request to get that part removed. Sorry about that.
Also, CP accounts cannot utilize AVS as it's designed for CNP (Card-Not-Present) accounts only. That's why you aren't seeing where you can edit that setting in the Merchant Interface and you're getting an AVS response code of P, which means AVS isn't applicable.
Hope that helps.
Developer Community Manager
03-10-2011 08:35 AM
Anyone can explain me how i configure my test account in test.Authorize.net for i can submit order in non-USD currency?
I'm doing's a in web site that i need to accept multi-currency.
I implemented AIMI and i just put x_current_code in form but i receive the same error:
he supplied currency code is either invalid, not supported, not allowed for this merchant or doesn't have an exchange rate.
In test account i just put AVS - BERGUSN to Allow, and the situation is the same.
03-10-2011 12:01 PM
All transactions have to be in US currency. If you want to accept other currencies you'll have to do currency conversions to US dollars before submitting the transaction.