Address Verification Errors and Address Line 1

[srmb]

So for awhile we've had this problem with certain card transactions, usually Visa it seems, where an address mismatch error is generated through our card processor Authorize.net even though the customer's address is actually correct. Addresses that generate this error always follow the pattern of a numbered street name following the house number. Example: 1234 5th Street

When a credit card transaction is processed, the only pieces of information that are actually verified in the transaction are numbers: the card number, expiration date, ccv code, and the house number. The name on the card, the street name, city name, state name, etc. are not used for verification purposes. So, if we run these same card transactions manually by getting the card number from our customers and processing the transaction on a physical card terminal, then there is no error of course because the address is correct.

So, I have a feeling that what is happening has to do with "Billing Address Line 1". Instead of the card processor (Authorize.net) recognizing the house number as "1234", it also sees the number in the street name and is instead trying to verify "12345", which returns an address mismatch error.

Has anyone else experienced this kind of issue? I thought about creating separate fields for the house number and street name on the checkout screens, but I want to make sure that the information is being passed correctly from screen to screen throughout the checkout process. It seems that the "Billing Address Line 1" field goes through some name changes from page to page, so I'm not quite sure how to proceed.

OCST: &mvte:global:BillAddress1;
OPAY: &mvte:global:Basket:bill_addr1;
INVC: &mvte:order:bill_addr1;

Can I use the "Billing Address Line 1" field for the house number and create a second field for the street name? If so, how can I correctly pass the new street name field on each checkout screen? Or is there another/better way to fix this?

Thanks,
Shannon

[SunCam]

We only recently started checking name, address and zip match in our store. We never had a problem with fraudulent credit card use before the change but the added fees for NOT checking were making the practice expensive.

Since making the change we have had a couple of irrational declines from Visa but we cannot draw a similar relationship to the address structure. All of ours were of the format of 1234 Tooterville Lane and in one case the customer tried 7 times and claimed to be reading his address directly from his Visa bill. We do not take mail or phone orders so we lost the sale (and probably the customer). I would have changed the Merchant Interface settings to allow his transaction to pass but by that time he was too impatient to experiment further.

If this problem persists we will drop all of the match settings and go back to simply accepting all credit cards as long as they have a valid card number. We are fortunate to have “theft proof” products but have not devised a method of preventing gouging by the credit card industry.

I will be interested in hearing any solutions offered by the forum.

[Rick Wilson]

I confirmed with Dev that we combine the whole address back up and send it as a single entity to Auth.net, so nothing is "breaking" on a mapping basis.

Something else was/is wonky at Auth.net in this case.

[srmb]

Well this is something that Auth.net has had as a problem for years as we have had this issue ongoing for a very long time. I actually called Auth.net a couple years ago to tell them it was happening and they just said that any address mismatch errors are because the customer's address is not matching the information on file with their credit card company and that they (auth.net) couldn't do anything about it. But I know this is wrong because this problem happens so many times with the exact same variables (Visa cards with addresses like 1234 5th street). As I mentioned, we can get the customer's card number and address information and manually enter it on our credit card terminal and it will go through as exact match with no errors. Any thoughts on this? We lose customers over this issue. We have to apologize and tell them sorry, you have one of "those" addresses and hope they will complete the transaction over the phone with us.

Thanks,
Shannon

[Rick Wilson]

It could be something in your Auth.net fraud settings. We've used Auth.net for years and I've never seen that.

[srmb]

I just looked at our fraud setting in Auth.net and I don't see anything that we can change to fix this problem short of just accepting cards even with a street address mismatch. Under general AVS responses we reject B, E, R, G,U, S. Under Address and Zip responses we reject N, A, Z, W. Since your company uses Auth.net, what AVS settings do you use?

Thanks,
Shannon

[srmb]

I just went through our orders in Auth.net for the past month and found that probably 70% of the declines due to street address mismatch followed the pattern I outlined above: a Visa card with a street address with two or more sets of numbers in the street address. Here are a few examples:

1. 1000 N. 4th Street / MR25
2. 443 33rd Street
3. 13740 N. Highway 183 Ste 4
4. 1848 110th Street
5. 528 38th Street
6. 606 5th Street

There have been just too many of these with the same pattern for it to be circumstantial.

Shannon

[Rick Wilson]

As a rule we let virtually everything through Auth.net and we use the MaxMind module to stop fraud.

[srmb]

Hmm. I checked into MaxMind and I don't see that it does any AVS checks. I thought address verification is what made transactions the most secure and gave merchants the best card processing rates. If you bypass AVS, what risks are we taking as merchants?

[Rick Wilson]

AVS has no impact on rates you pay to your merchant processor.

MaxMind doesn't use AVS per se, but they do compare the location of the IP address with the actual Address on file at the bank and that's one of the key things they use for determining their score.

[srmb]

So I'm revisiting an aspect of this problem. It seems that when a customer enters a comma in the address field, when the transaction is run through Authorize.net it changes the comma to ","
Here's an example:

Address:

48-50, 44th Street, Apt 5D

Of course this is getting declined as a street address mismatch.
The address field is displayed with &mvte:global:BillAddress1;
Is there something I can do to prevent commas from getting submitted as code? Or is there a way to prevent commas in the address field?

[Asim77]

Hello, having a similar issue with Authorize.net, sounds similar to the comma issue above. Did anyone get this resolved? If so, what AVS settings are you using in Authorize.NET?

[srmb]

No I never got any other feedback or support to fix this issue. Miva says it's not a problem on their end as they only pass on the error message that they get from Authorize. And Authorize says it's not on their end as they are only verifying the address on record and if it doesn't match then it doesn't match. But obviously it's a consistent repeatable issue and we still have it. The only solution Miva gave was to forego address verification.

[Bruce - PhosphorMedia]

This sadness reminds me of my brilliant idea to stop most online CC fraud. Simply tie a CC # to an email address. When the gateway gets an order...it sends the info to the email address. Someone else orders something--you get an email...with the shipping address. So, fraud attempts could easily turn into 'sting' operations.

I mentioned this to an 'unnamed' payment processor once...he just nodded his head yes...and said, no.

[Asim77]

LOL Bruce! It actually sounds like a great idea!

I think we should push a little more for clarification on this issue.