AVS mismatch prevention

[jrockfl]

Hello! I have been reading over these forums and finally decided to join.

Currently, we're using Authorize.net and Chase Paymentech for credit card processing.

We have AVS enabled, but we get a lot of calls about customers thinking we have billed them twice and we have to explain it is an AVS mismatch, etc.

Tonight we had a customer that had a total of 3 transactions, the first 2 two were AVS mismatch and I had to hear how this was an inconvenience to her and she has bills to pay, etc.

How do you handle AVS mismatch?

[enigma1]

Hi jrockfl welcome to the forums.

Not sure about the setup on your store but how do you manage to bill the customer on an AVS mismatch. As far I know anet will return a response error of 2 or 3 ie: the transaction is declined or an error occurred.

If your code ignores the AVS mismatch during order placement it could explain the problem you see.

There is also handling for duplicate transactions. Best to study the anet API and use the AUTH_ONLY for the initial processing.

[jwolthuis]

Welcome to Webmaster World!

I think the workflow goes something like this:

(a) Customer uses their card (typically a debit card, not always a credit card), and mis-types (or doesn't know) their billing address. In the case of Business Visa cards, a lot of them don't even know their billing address, as it's likely some obscure PO box back at corporate headquarters.

(b) For a Debit card Auth-Only, their bank verifies the funds in the checking account, and places a hold on those funds (appears as a "charge" to the customer). The merchant does not have those funds, just an authorization; the bank earns interest on the held monies.

(c) The bank immediately notifies Visa of the pending transaction. Visa performs an AVS check on the billing address, and returns a status code.

(d) Based on the settings tied to your merchant account (some of which you may not be able to change), the transaction gets rejected for AVS mis-match.

(e) The customers' bank doesn't immediately release the hold on the funds, but rather queues the request, which can take 24-48 hours to process. They continue to earn interest on the held funds.

(f) Customer rants at the merchant for the hold placed in step (b). Merchant has no order to match with the held funds. Bank insists that the merchant must void the failed transaction (that the merchant has no record of even succeeding in the first place).

We deal with this scenario by disabling AVS (so that AVS mis-matches succeed). But we view the AVS code, and make a risk assessment, based on order size, destination country, customer order history, etc, prior to shipping the order.

[enigma1]

As far I know anet supports zero dollar authorizations to test the cards specifically for AVS and the problems you have. If the card type doesn't support it you can offer alternative payment methods to the client.

Charging the customer and then declining the order is not a solution.

[jrockfl]

Thank you for the replies.
jwolthuis I'm going to give your method a shot and not enable AVS and make the risk assessment. What is your process for making the assessment?

We have gotten better and spotting fraudulent orders and will cancel them on the spot.

[jwolthuis]

Charging the customer and then declining the order is not a solution.

Agreed. Debit cards are problemetic, because an Auth_Only appears on the customers bank account, until their bank gets around to removing the Hold. This should happen instantly, but often takes a day or two. Meanwhile, the customer is out their grocery money.

Zero-dollar auth's are a great solution. They are not free, however. If you pay a quarter each time you touch your payment processor's API, you're up to 75-cents to fulfill even the most basic order (zero-auth, auth-only, capture). I'm not convinced that the solution is worth the added expense.


@jrockfl: If the AVS non-match was due to outside problems (country/bank doesn't support AVS, AVS-network down, etc), we fill the order.

We look at all other AVS non-matches, and if the order is for a significant amount, we call/email the customer, explaining our concern about the billing address. Usually, they have a valid reason; just moved, getting divorced, at their summer cottage, etc.

If we receive an unsatisfactory response (or none at all), which happens in <1% of AVS-problematic cases, we will void the authorization and close the order.

[jrockfl]

@jwolthuis

Thank you, so far most of the transaction matched on both address and zip. There were a few that only matched on one, but that is not a problem.

We will keep watching it as time goes out, but I think this will turn out better for us.

[enigma1]

If you pay a quarter each time you touch your payment processor's API, you're up to 75-cents to fulfill even the most basic order (zero-auth, auth-only, capture).

Are you sure it's a quarter? From what I read is 0.025, not 0.25

reference:
[cardfellow.com...]

$0.025 - Zero Dollar Verification Fee
The Zero Dollar Verification fee applies to Zero Dollar Verification messages (approved and declined). Zero Dollar Verification messages include the verification of the card account number, address verification (through AVS), Card Verification Value 2 (CVV2) and Single Message System (SMS) acquired Account Verification authorizations. The Visa Misuse of Authorization Fee does not apply to these requests. The fee applies when you want to verify a cardholder's information without actually authorizing an amount of their card.

[ivorobey]

We have AVS enabled, but we get a lot of calls about customers thinking we have billed them twice and we have to explain it is an AVS mismatch, etc.

We had the same problem with customers emailing us about being billed twice. Later on we found out, that when customer enters the credit card information and gets the AVS error or the invalid card number error, they try to proceed with the exactly same information again. At this point they get an error from authorize.net about submitting a duplicate transaction. All we did was to make the authorize.net errors more noticeable to the customers and that solved the emails about duplicate transactions, because the customers started to pay more attention to the first error.

Thank you, so far most of the transaction matched on both address and zip. There were a few that only matched on one, but that is not a problem.

I had a big argument last week with my merchant company about the customer winning charge back because of this problem. According to the merchant company 2 billing AVS fields have to match per visa's guidelines, and we only had zip code matched, but street address did not, that's why we lost the charge back. I just thought to point it out if you are looking to take the risk.

[jrockfl]

So far things have been going well, no more of those annoying calls or emails.

We had both zip and street address enabled for awhile and we got some many calls and emails/ especially during the holidays. We reduced to just 1, but now we have totally turned it off.

[Realbrisk]

You can always use Auth.net Fraud Detection Suit, that will give you an option to review and capture all the Avs declines while having the the regular Avs settings in place

And speaking of Debit card declines we have has customers card declined due to to avs, customer insisted its is the correct address, it turnd out that not always when you change the banking info does the debit card info get updated