Forum Moderators: buckworks
The cardholder calls her card issuer bank. They tell her absolutely nothing is wrong with the card, plenty of funds are available and no fraud screening would have been triggered by the transaction. Furthermore, a great many of these customers assure me they have already used their cards for USA transactions before with no glitches.
But here's the kicker: in all of these instances, the card issuer bank has no record of a charge attempt ever even having been made. An abort is going on en-route, so that the transaction does not even reach the card issuer, while on my end I get a straight decline message.
I contacted support at my credit card solutions provider, EXS, and after a lot of back & forth I finally got transferred to a deep geek, a coder, a guy who really knows what's going on. First question out of his mouth is: Are you using Authorize.net? He's been hearing a lot of the same complaint, and Authorize.net is the common thread among them all.
Authorize.net support has been exasperating to the point of surreality. Their first response clearly indicated they had not even read the eMail, which had been brief and very specific. In response they pasted a whole bunch of boilerplate FAQ blather about AVS settings.
These were straight declines, not AVS declines, regardless that AVS does not work on international transactions, that AVS was not given as the reason code for any of them, and that in fact all AVS screening has always been turned completely off for all of these transactions.
After much frustrating discussion, Authorize.net eventually they came back with: there is nothing wrong with Authorize.net, so the issue must be caused by my processor, Global Payments, and I should contact them.
And so I did. Global Payments said the fact that the charge attempt never even reaches the card issuer bank defines without any question whatsoever that the issue is not with Global Payments. The nature of their role in processing is such that Global Payments cannot be the causative factor in the decline, and rules out their role, as a physical impossibility.
So...I've relayed that back to the Authorize.net, desperately hoping they move me up the food chain to someone who actually knows what he is doing. It's incredibly frustrating.
These declines are costing us a fortune in lost sales, a very significant amount of money. They also irretrievably alienate (ie: lose) a big chunk of our new customer base, who end up not buying from us at all. It's hard enough as it is to allay fears and suspicions with international credit card transactions over the net. If I contact the customer about a decline, and the customer then calls his bank to discover that no charge attempt had even been made, all red flags go up in his mind, he suspects fraud and the potential for any further cooperation from that customer is shot. Note that in instances where we have been able to get customer cooperation in these declines, and have re-tried PayPal with the same previously declined card numbers, the charges go through successfully.
Note: to preclude any simplistic (if well-intentioned) replies, just take my word for it that wire transfers in advance are not a possibility, nor is a switch to PayPal as my site's payment method.
Has anyone here had a similar problem with Authorize.net and international cards?
How did you resolve it?
[edited by: lorax at 3:32 pm (utc) on Mar. 10, 2005]
OT question: how are you validating your international charges? I too have AVS turned off, but this allows, for instance, some jerk to input random numbers until he gets something to hit. I've been using MaxMind to calculate the probability of fraud, and if a charge raises any flags, I ask for the customer service number from the back of the card. But some customers get very upset with that request, and some just don't answer - partly, I suspect, because their English isn't good enough. So how do you handle that, if I might ask?
-Corey
Our other clients who have this problem find that if you can find out at least the first few digits of the declined cards (so no customer confidentiality issue) then it is possible to contact the issuing bank and see if they have, for any reason, a block or default decline on your site, jusrisdiction or product type.
A short email is usually all it takes (if sent also to the local card assoc) to get this lifted, then sned this to authorize.net and see if this solves your problem.
If the tx is being declined before it even goes to auth then as the other writers say its almost certainly a gateway (Authorize.net ) problem.
But the other question is that if you are running decent volumes why are you still using a gateway? This is cost and complexity for no reason, and virtually all our clients drop them when they see the benefits (NOTE - We are NOT a gateway, so don't have any axe to grind about them).
Regards
Jag
EVO
Now, I have a different problem (BofA debit card declined all the time!)... not to derail this thread though.
