Authorize.net and AVS

[deepsand]

Originally Posted by ladraut

This is amazing that so many think that authorize dot net is doing the authorization.

They are just the payment gateway between your shopping cart and the authorizing merchant bank.

Aint' it so!

This despite the fact that every transaction confirmation e-mail to the merchant contains the following :

========= SECURITY STATEMENT ==========
It is not recommended that you ship product(s) or otherwise grant services
relying solely upon this e-mail receipt.

[Shift4SMS]

The issue you describe is not technically an Authorize.net issue; instead it is a limitation of the VISA/Mastercard network. They are not going out for the auth first and then the AVS, both happen at the same time and authorizing the funds while still returning an AVS failure is common. I think others have mentioned that the funds are not actually taken from the account, but the open-to-buy does lock the funds so to the cardholder, they feel they've been screwed the same.

Anyway, out gateway has what we call two pass AVS logic and the thresholds, as well as the valid AVS responses can be adjusted based on the merchant needs. In a nutshell, if the transaction amount is over some threshold ($25 by default), then we go out for a $1 auth only transaction first. If the response comes back with a valid AVS response, then we turn around and do the full authorization -- this way, in you example, we're only dinging the cardhold $1 for every failed AVS request as opposed to the $500. Whether or not the $1 AVS auth passes or not, we discard this transaction and the cardholder will eventually have access to this money once the auth expires.

Our gateway does this automatically behind the scenes but you should be able to impliment it yourself with most any gateway (not Paypal though). Hope this helps.

[Scout]

We have used Authorize dot net with AVS for many years. To reduce the number of AVS errors we receive, we made the following changes.

Put a Warning on the Billing information page that it must match the billing address on their credit card.

Promptly send an email to the customer upon receipt of the AVS error explaining that it a security feature for their protection as well as ours and suggest they call us so we can resolve the problem. This has been 99% effective.

On the rare occassion that an AVS error occurs with a valid address, you can do a Capture only transaction using the Authorization Code provided by the AVS error transaction.

These measures have reduced the number of AVS errors which occur by 90% and we rarely lose an order when they do.

Hope this helps.

Scout

[msinfo]

Scout, you've made my point exactly. As you know and many successful merchant's that I've also helped know, the merchant that we deal with can attest you cannot sit back and not monitor your transactions. The best way to combat fraud and to respond to red flags and that includes AVS hiccups.

Thanks for shedding light with your response.

The best way to utilize AVS and still not miss sales where the address doesn't match is to respond pro-actively when the address doesn't match.

[wdillsmith]

Originally Posted by Shift4SMS

The issue you describe is not technically an Authorize.net issue; instead it is a limitation of the VISA/Mastercard network. They are not going out for the auth first and then the AVS, both happen at the same time and authorizing the funds while still returning an AVS failure is common. I think others have mentioned that the funds are not actually taken from the account, but the open-to-buy does lock the funds so to the cardholder, they feel they've been screwed the same.

Anyway, out gateway has what we call two pass AVS logic and the thresholds, as well as the valid AVS responses can be adjusted based on the merchant needs. In a nutshell, if the transaction amount is over some threshold ($25 by default), then we go out for a $1 auth only transaction first. If the response comes back with a valid AVS response, then we turn around and do the full authorization -- this way, in you example, we're only dinging the cardhold $1 for every failed AVS request as opposed to the $500. Whether or not the $1 AVS auth passes or not, we discard this transaction and the cardholder will eventually have access to this money once the auth expires.

Our gateway does this automatically behind the scenes but you should be able to impliment it yourself with most any gateway (not Paypal though). Hope this helps.

This is actually similar to what I am considering doing in our system. I'm not sure whether the $1 charges, even though they are voided, will result in even more phone calls asking why our company charged them twice. I'd hate to invest the time in solving one problem only to create another.

[crankydave]

Originally Posted by wdillsmith

This is actually similar to what I am considering doing in our system. I'm not sure whether the $1 charges, even though they are voided, will result in even more phone calls asking why our company charged them twice. I'd hate to invest the time in solving one problem only to create another.

Exactly. While it's a workaround, the client/customer is going to see 2 transactions likely prompting a phone call, or possible dispute.

Dave

[Thelma Brown]

Right couldnt have said it better myself, I had this same problem recently and no one is at fault but the customer who entered in the wrong billing address. It will happen like that you may be charged several times,

[Shift4SMS]

It all depends on your average ticket and target customer. If your average ticket is low, under $50 or $100, the $1 auth will probably not cut down on the number of complaints. If your target customer commonly use debit (check) cards, these tent to have lower and hard limits and will generate complaints more than a true credit card account (all things being equal).

Another thing to consider, use a tokenization solution and keep the billing address and a token on file (card on file). Allowing return customers to use a "card on file" to check out will cut down on this issue because the AVS will have already been done on a prior order and will most likely be the same.

Good luck.