We've had three confirmed cases of CDG declining cards that are known to be good. Generally, it goes something like this:

Customer tries to pay via our CDG gateway, and gets a decline.
Customer emails us insisting their card is good and asking why it isn't working.
We try the customer's card from the backend, and also get a decline. We then tell customer to use another payment gateway (e.g. Google Checkout/PayPal)
Customer does (using the same card) and the payment is successful.


This happens predictably and repeatedly; for one customer this has happened three months in a row. Both Visa & MC, cards from USA and Intl. CDG says that the bank is issuing a decline; I've had the customers call their banks, and the banks say that they don't see the transaction coming through at all.

I've contacted chris & co at CDG, and they are looking into it, and think it might be something with their front end network. However, its been about two weeks and they haven't been able to get it sorted yet, so I thought I'd try to gather some more debugging info for them.

My question for you all: Has anything similar happened to you, either with CDG or with another card processor (auth.net, etc.)?

The customer could be providing information that does not match what the card bank has on file, which can make it be declined depending on your settings.

Been using CDG since March 09, 2007 never encountered that problem.

tumble

I agree, I've been using CDG for over a year, not a hitch in the system at all.

There are a number of reasons the check could be declined.

#1 : Maybe your client isn't being oh so honest and doesn't have the money on the account?

#2 : Maybe the bank has frozen the card due to any number of reasons, such as too many charges, too many failed attempts, too many problems. I've even seen some (Paypal) freeze the card when the client takes too much money out.

#3 : I've run into certain instances in CA where zip codes don't come up properly on AVS. This isn't the client's problem, but a problem in how AVS is handled.

The best thing you can do here is call your processor directly. If you're using authnet, give them a call, they will happily tell you exactly why the charge is failing. If you're using cdg's processor, give THEM a call. Don't let them off the phone until you know exactly what the problem is and can resolve it.

Using CDG for almost 3 years, never had this hitch with them.

Chat them up on livechat and see if they can assist you :)

Thanks for the replies, guys. I guess to reiterate a couple of points, and add a few new ones:

- Some sort of AVS mismatch or the like is what I suspected, but we have everything turned on (e.g. allow card for AVS mismatch, allow card for CVV mismatch). We use the 3D Secure system for fraud protection, and all three customers report entering their PINs and getting a 'card authenticated' message (or similar).

- I don't think the card itself really is bad, because the customers all report being able to use it in other places (and even pay us with it via another gateway). If the card didn't have funds, etc. that wouldn't be the case.

- We told CDG about this issue two weeks ago, and they've been working on it, but no luck so far. That's why I wanted to get more info from everybody... figure that it other people have seen this problem, then its probably CDG; if its just us, I don't know... might be our billing SW or something (we use WHMCS)

Does your gateway web interface have a "virtual terminal" or something similar where you can manually enter the card information and try an authorization? If you get the same result, that likely rules out your billing application. Also, if you're using an API integration method, you might try logging the entire response string you receive after sending a transaction to the gateway. You'll typically get more detailed error/reason codes that way aside from just a decline, which you can then parse to try to diagnose the issue.

Anything related to AVS won't affect the issue you're seeing if your customer (and their card issuing bank) is claiming to not see the transaction. An AVS mismatch still generates an authorization irregardless, but it typically marked for non-settlement by your processor (depending on your AVS settings, but you have those turned off anyways).

Hi Dordal,

We have been unable to duplicate the issue despite a huge amounts of tests that we have run with our front-end.

I do have another idea, however, that I will PM to you on something that we could try to further try to figure this out for you.

Google Checkout does this periodically for me as well as authorize.net has done this in the past. I know authnet seemed to have fixed the problem a year ago. However google still has this problem. For authnet i believe the problem was in the gateway servers themselves failing to try and charge the card from the merchant bank and instead automatically declining the card.

I have a lot of charges that recur monthly, and a certain proportion of them fail. Some of those fail for valid reasons, others make me wonder. I have no way of knowing if they all fail for valid reasons or not, but sometimes it seems that several fail one after the other. Sometimes, when I retry the charge a few days later, it works. Like I say, I don't know what's going on in the background, or if CDG deserves any blame, but it's frustrating.

In the 4+ years we have used CDG Commerce, I have seen this happen to us only once.

(We were using the authnet gateway at the time...)

Customer had their card declined, and then it worked fine when we charged it manually using a different processor (not authnet).

I think part of this problem is the lack of information returned by the cardholder's bank when the charge is attempted. I've had this happen myself when paying for something at a retail store, where the card was not accepted. Then I drive 2 miles down the road to buy gas, and the card works fine.

When I called my cc bank to ask why the first charge attempt was declined, they told me that "internal security systems" had determined the charge attempt was not valid. No other information was given to me, the card holder.

Anyway, I have absolute complete confidence in CDGCommerce. they know what they are doing.

We use CDG and this never happened.