Merchant Account Problems

We're currently running a custom e-commerce platform on our site and using Authorize.net/Verisign as our payment processor and Wells Fargo as our merchant account. What we're finding is that about 50% of our transactions seem to be getting declined. We've tested our own cards and those seem to go through fine. But when we look at shopping card abandonment numbers and reports from Authorize.net it seems that we're losing a lot of people on the Payment page and seeing a high number of declines.

Two questions:

1. Has anyone dealt with this issue before and if so, were there any remedies? Obviously it's tough to offer advice given that every situation is different and we're running with custom code rather than an off-the-shelf shopping cart. But if anyone has any suggestions here please let me know.

2. We're contemplating switching over to Paypal as it seems that might be a cleaner solution. We also like the ability to allow someone to pay with Paypal directly instead of a credit card. I'd love to hear peoples' thoughts on this. Also, we're going to have a need to do micropayments and from the research I've done it seems that Paypal would work for this (although we would have to set up two accounts I think).

I'd love to hear any and all thoughts on this matter. We've spent a lot of time and energy putting our shopping cart in place and while I'd hate to rip out what we have I don't think we can keep turning away customers at the rate that we are.

Thanks!

 

I have heard this about Wells Fargo. A friend of mine used to use them, and he switched because they did not accept too many orders.

 

Do you get reasons for decline? Maybe the AVS is set to only accept orders that are YYY, or requires a CVV code, or maybe even VBV.

I've never used wells fargo, but it doesn't seem like its a merchant account issue so much as gateway settings.

 

I have never used them either, but a friend was having the exact same trouble. I'm pretty sure it was not a gateway issue in his case as I imagine he certainly would have checked that...

 

Since you'll need micropayments I suggest you use Paypal. We have been using them for 2 years now and it works great. Set up a business account with paypal, customers who have a paypal account can pay directly with paypal. This ia a very nice feature to have since many people have paypal accounts.
Its also very easy to integrate it with your website

 

Can you elaborate a bit on what you mean by "YYY, or requires a CVV code, or maybe even VBV."? Another guy at our company handles this and some I'm not 100% familiar with all of those terms.

We do require the three-digit verification code to successfully process a transaction.

I'm viewing the Authorize.net reports right now and can't see a reason for the decline. I guess I'll need to wait until their customer service opens in the morning.

Thanks SO much for the help thus far. This is very important (obviously ) to our business right now.

 

YYY means AVS is a complete match.

 

YYY - address verification gets several response codes, depending on the customers input. YYY -- address good and zipcode good, NYY- address bad, zipcode good, YNY - address good, zipcode bad. Problem with only accepting orders that are YYY is that banks are slow to update sometimes when someone moves.
More here: http://www.emsecommerce.net/avs_cvv2_response_codes.htm


CVS - the 3 (or 4) digits on the back of the card. Supposed to verify card possession. But since there is a 1 in 1000 chance of guessing it, its not too reliable for card presence.

VBV - verified by visa.

If you can't see a reason, call them up and see if they can see the transaction reaching them. It could be a connection issue. I've heard of issues with wells fargo in the past, but I don't know a lot about their service.

 

OK, cool. This is really good help. I will be checking with the account providers ASAP and see what I find.

 

Hi Paul.....I have a merchant account, it's a mainstream bank and have a similar problem. They only accept Visa and Mastercard which is ok as most cards are compatable. The problem I have is that the decline rate is also around 30/50%. Maybe that's par for the course.

I am guessing some of this is from people putting in the wrong details to try and get something for nothing.
What I would like to find out is what the code means that comes with the declined message. There seem to be three different codes.
I assume one is insuffucient funds.

 

Are you using Verisign or Authorize.net on the back end of the website?

There are several things that quickly come to mind when I read this. First off as stated, your AVS / CVV settings may be too strict and you are getting declines due to AVS and CVV problems. If you are using Authorize.net go into your account settings and check your account settings. Check to see what you AVS is set at and check to see what your CVV is set at. Depending on the products that you sell, you may not need extremely strict settings. Street Address match causes the most problems.

Here is what I set sites at by default as long as they are selling to US businesses only. This blocks all non CVV and AVS transactions but allows them if the street address is incorrect.



The other option which I have seen only a few times, and is much more difficult to correct, is SIC code mismatch filtering.

This is a virtually unstoppable problem that has to do with banks protecting their customers from making certain types of purchases. I was completely unaware of it as most people are until our company had a problem with it on one of our websites.

Basically when you business sets up its merchant account, it gets classified by a number called a SIC (Standard Industry Classification) code. The code is assigned based on the method you use to accept credit cards and the type of products that you sell. Some card issuing banks filter transactions from certain SIC codes because they are associated with a higher amount of fraud. Example, some types of online electronic stores are filtered because of their high fraud rate, so any time a customer with a card from the bank that filters is processed there, it will decline. Every time, no matter how much information is provided with the transaction.

The problem with this, is that most processors don't know it exists, and the only way to charge it is to get your businesses SIC code changed. The good thing is that this problem is very rare, and should only be considered after every other possible thing is eliminated.

Personally I would not even think of switching to Paypal as a primary means of accepting payments. For a serious online store, paypal makes a great alternative form of payment, but IMO should not be the primary.

 

I would suggest that you do a couple of experiments:

The CVV code has already been talked about here. Try eliminating the CVV code requirement and see how this effects the percent of declined transactions.

The 2nd experiment I would suggest would be with the address verification. Try turning this off (assuming you have it on) and again see what happens to your decline stats. I would guess that it is this that is causing your problems. However, I would say that I believe this is the most important fraud prevention device. I have been amazed at the number of fraudulent transactions that have been attempted with our site. They usually don't have the correct street address though.

 

If you are receiving excessive hard decline responses from the Visa/Mastercard network, there are several possibilities and here are some of the most common:

1. You have a lot of customer using your site with maxed out credit or debit cards (unlikely)
2. The CVV2/MCC code is incorrect which will generate a hard decline from the issuer
3. Excessive number of transactions in a short timeframe (I think I saw some reference to micropayments; while a micropayment by itself will not cause a hard decline, 4-5 in a row for the same card can)
4. Merchant account setup problem related to the ecommerce indicator (if you are not setup correctly, the Visa/Mastercard network might think you are processing a "card present" transaction which could trigger various automated fraud prevention screeners)

#2 can be caused by the customer entering the wrong codes or a programming error between your site and the gateway.

There have been several references to AVS settings -- these will not cause a hard decline from the networks as the AVS system and the normal authorization systems are two separate systems. It is possible (and common) to receive an approval response with a total AVS failure. If you are seeing decline responses related to AVS, then it is the gateway stepping in and declining the transaction. I think others have given advice on how to solve this issue if it is the cause.

Hope this helps.