AbleCommerce Shopping Cart Software

Hi,
I'm sure many other people are having this problem. We're setup with Authorize.net through wells fargo. Setting is Authorize and Capture. However, whenever there is a decline due to AVS mismatch or CVV mismatch, our customers complains that the transaction appears on there credit card. Some customers get super mad about this and its becoming a real headache. Authorize.net hasn't been too helpful in this since they say its a processor issue and they can't do much. after a bit of reading around on the net, many were suggesting to do a auth for $0 and if its successful, do a auth-capture for actual amount. Is this possible in AbleCommerce? if yes, does anybody have any code available on this? Many other said $0 auth is not supported and you have to do $0.01 auth and void it. and what are other alternatives if any to resolve this issue?

Thank You,
Vick

This hold is normal. The hold goes away after a few days if you don't capture it, but that might not be a help to the customer especially if it's a debit card.You can call the card processor and have them remove the hold on the money if you are not going to process the order. You can try voiding it in authorize net also. At least that way you could send the customer a screen shot that it was voided. I think there are some fairly new card processing rules that disallow running a test transaction for authorization purposes.

Allow me to add...

There are two situations where this (hold/pending on customer's account in spite of AVS Mismatch) can occur.

1. If you have set up fraud filters in Authorize.net
The you are essentially asking authorize.net to check one or more factors; some of which can (and are) checked before the bank/card issuer gets a chance to approve the transaction, some of which can only be checked after the bank/card issuer approves the transaction. Those that are checked after approval that cause a decline based on those fraud prevention checks are the issue.


2. If you have not set up fraud filters in Authorize.net.
There are a small percentage of card issuers (banks) who issue the "authorization code" and place the hold AND THEN check the address for verification. I would estimate about 2% or so have this logical flaw. I've experienced it more often with Canadian banks than with US banks. (And most banks in other countries do not usually provide address verification...you'll see that when you look at the AVS codes.)

Basically, the difference is that in case 1 you essentially caused the issue by asking Authorize.net to get an authorization and then asking them to check other potential fruad factors. In case 2, the bank just has bad logic.

In either case the advice jestep provided is correct. Have the customer contact the card issuer (as there might be other reasons for the decline, too). If the customer is approaching or exceeding their credit limit, then either the customer can add you into the conversation with the bank (I've done this many times, quite successfully) or they can give you the information to call the card issuer directly. Note this all seems to work better with Visa, MC and Discover better than with Amex. If the customer is not running into a credit limit issue, then just tell them that the transaction will never be presented for "settlement" and will disappear (the hold will go away) after some number of days (which also depends on the specific card issuer.) In my experience, most customer just want to know that they didn't get charged more than once...and, as jestep stated sometimes a copy of the "void" transaction is enough to satisfy them.

As I said before we do auth-capture. auth only doesn't work well with our operating procedures. Authorize.net said same thing to try to call to release funds faster which is really not possible when I've so many transactions with this issue. i'll to hire a full time person just doing this. The bottom line for my customer is they see the pending payment when our website is saying payment declined. This confusion generates 10%+ of our customer service time and very unhappy customers even after explanation of all this crap. Any transaction that is declined because of AVS doesn't have void button authorize.net and so it really takes its course. All i see is transaction status:

"Declined (Authorization with the card issuer was successful but the transaction was declined due to an address or ZIP code mismatch with the address on file with the card issuing bank based on the settings in the Merchant Interface.)"

some customer retry the transaction and end up showing multiple transactions on the card as pending.

Transaction pre-authorization in AC is possible, but it would require custom changes in the checkout process logic. Another disadvantage of credit card pre-authorization are the
additional fees associated with the pre-authorization (Auth.Net will charge separate AVS and Transaction fee for each transaction).

Another option is to adjust the AVS settings in your Auth.Net admin interface to allow all transactions with no Address and ZIP code verification. In your AbleComerce admin
interface set the AuthNet mode to Authorize. With this configuration all transactions will go trough, but will have to be manually verified and captured from within the Auth.Net
admin interface.

Manual transaction authorization requires additional work, but from our experience is the only way for detecting fraud and avoiding chargebacks.

What if i do a auth first and if auth approves, i can do capture right away. will this type of transaction show up in customer credit card as pending during AVS mismatch?

Yes, the auth. transaction will reserve the requested amount and the transaction will show up as a Temporary (Pending) transaction regardless of the AVS status. We tried this method
in a custom payment gateway we developed for our domain registration service in order to prevent fraudulent domain registrations. Disabling AVS and manually verifying each transaction
is the solution that worked for us.