AVS implementation details

Failing fast on known-bad billing addresses

[jollymcfats]

When AVS comes back bad, some of my customers will re-try their purchases quite a few times, often with only trivial changes to their street address. Each of these AVS-declines leaves a temporary auth on their card account, and with our Authorize.net gateway, these don't seem to get fully voided until the batch closes.

These temporary auths tend to really freak people out, and I'm working on a filter to cut down on AVS declines by simply not submitting duplicate information to the gateway. I've read that the street address check is numeric only; only the first "x" numbers in the street address are used in the AVS check.

So my question is: how many digits are significant in address checks, and are there any agreed-on for rules picking which are used? E.g.:

123 9th Ave Apt 45D

could be 123, 1239, 123945, etc. with the alpha characters stripped out.

[Corey Bryant]

Usually it is 123 and also the ZIP code. Also - with these, doesn't authorizenet.com charge you for that transaction (hitting the gateway)? Also, see if they have something that can actually "block" it.

For example, LinkPoint has a setting that will block the same credit card number and the same amount for XX amount of time. I usually have my clients set this for about 20 minutes, depending on what they are selling.

-Corey

[jollymcfats]

> Usually it is 123

When would it not be 123, and if not, what?

[Corey Bryant]

I used your example

123 9th Ave Apt 45D

Now, if it was

987 9th Ave Apt 45D

then it would be 987

-Corey

[jollymcfats]

Sorry, I was thrown off by the word "usually". So you're saying that it is _always_ the first set of contiguous digits found in the street address, terminated by any whitespace or non-digit character?

123 9th Apt 45D
PO Box 1234
RR 1 Box 1234

[Sunshyn]

I sincerely doubt one can use the word "always" when dealing with the AVS system.

We get AVS match errors on a fairly high percentage of perfectly straightforward addresses where, when we later call the issuing bank directly, they tell us that address information was correct.

Speaking of authorize.net, we just affirmed the fact that we're at least occasionally getting a no match on the security code due to wrong expiration dates. Makes no sense to me. I guess "always" doesn't even encompass attempting to match 3 digits to 3 digits.

[jollymcfats]

> I sincerely doubt one can use the word "always" when dealing with the AVS system.

That's a good point. For something mission-critical for ecommerce, it is bizarre how unpredictable and unreliable the system is. Especially for Visa/MC debit cards.

I can't find any electronic specs for how AVS requests are packaged off to issuing banks- maybe it's a paper-docs-only kind of thing. Given the lack of that it looks like the safest thing to do is to consider all numerals in the street address for my purposes.

[Corey Bryant]

I'll try to ask for the specs. Unfortunately, it might be only for "my acquirer" - but it might be a good start

-Corey

[jollymcfats]

Update:

I did implement an AVS response cache in my checkout process, and have been running in production for a month now. The site is medium volume (< 1000 transactions/day) and it's been running great. We used to get at least one temporary authorization-related freak-out email a day. In the entire past month, we've received only 2.

I've settled on a cache lifetime of 8 minutes. This has been blocking all the real duplicate declines (average of 4, 30 to 90 seconds apart) but not so long as to interfere with a customer correcting their address with their card issuer. (Confirmed this w/ 2 customers.)

All said I'd recommend the approach to anyone with a custom cart and real-time auth/capture w/AVS.

[incrediBILL]

We had so many invalid declines with full blown AVS we had to set it to "street address or 5 digit zip match" to let the transaction thru. People in rural areas especially just couldn't checkout, it was a nightmare.

Almost nobody knows the 9 digit zip code which was annoying shoppers and the actual address seems to be even harder to get assuming you know exactly how the bank has it on your bill. Seems silly but it impacted about 20% of our customers when we have AVS on full tilt and lowering AVS didn't increase fraud at all.

As a matter of fact, the few frauds we ever have do better at getting past AVS than the actual customers :-)