| 11:43 pm on Jan 20, 2005 (gmt 0)|
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.
| 1:15 am on Jan 21, 2005 (gmt 0)|
> Usually it is 123
When would it not be 123, and if not, what?
| 1:36 am on Jan 21, 2005 (gmt 0)|
I used your example
Now, if it was
then it would be 987
| 1:46 am on Jan 21, 2005 (gmt 0)|
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
| 3:43 am on Jan 21, 2005 (gmt 0)|
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.
| 4:07 am on Jan 21, 2005 (gmt 0)|
> 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.
| 4:58 am on Jan 21, 2005 (gmt 0)|
I'll try to ask for the specs. Unfortunately, it might be only for "my acquirer" - but it might be a good start
| 12:32 am on Mar 3, 2005 (gmt 0)|
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.
| 12:40 am on Mar 3, 2005 (gmt 0)|
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 :-)