5

For the merchants using Authorize.Net as your gateway you might find this useful. If your customer’s street address or postal code contains a letter rather than a number, Authorize.Net AVS will return an AVS mismatch.

I use Authorize.Net and I’ve recently started shipping to Canada. I immediately started encountering problems with the Canadian postal codes (which contain letters) being shown as an AVS mismatch by Authorize.Net. Upon contacting Authorize.Net support, I was told that the customers were providing the wrong information. All of them? None of them know or used their proper postal code? That got me thinking.

I remembered a similar problem I was having with US street addresses that contain a letter rather than all numbers. Wisconsin is a good example of where this occurs. Every single one of those transactions returned an AVS mismatch by Authorize.Net. When I contacted Authorize.Net support when I first noticed this (was years ago) I was told that they do not support the use of letters in the street address. To double check, I went back over transactions submitted this year and sure enough, every single one that had a letter in the street address was returns as an AVS mismatch by Authorize.Net.

Now I don’t know where the problem lies. But there is a problem that does not lie with the merchants, and the response I got from Authorize.Net was completely unacceptable. More and more the onus of verifying information to help protect consumers from the potential misuse of their credit card information falls directly into the laps of merchants. At the very least, the AVS system should be able to be counted on by merchants as a tool to help them protect their customers from the potential misuse of their credit cards and themselves from potential fraud. I don’t know if the failure is solely that of Authorize.Net. But at the very least, as a merchant, a customer of Authorize.Net, I deserved an honest answer and some support for a problem that has existed for years.

Tags: , , ,

5 Comments

  1. Gman on the 30. Jan, 2013 remarked #

    Hey, did you ever sort this out or find an alternative solution your merchant problem?

  2. CrankyDave on the 08. Apr, 2013 remarked #

    Actually, Authorize.net finally sorted out their ‘issues’ and fixed the problem. 🙂

  3. Nate on the 06. Dec, 2013 remarked #

    We still have ongoing issues with Canadian addresses, with all failing to match postal, which I am trying to tackle now. The street addresses generally ARE matching fine.

    I am wondering if there is anything, that the postal code should be submitted with no space in it, or if this myth I heard has any truth that all the numbers should be sorted to one side and letters to the other, or if there is anything else I can do? Any wisdom would be much appreciated.

  4. CrankyDave on the 09. Dec, 2013 remarked #

    Hi Nate

    Authorize.net is still having issues with the postal codes from Canada. Space or no space doesn’t matter. About all you can do is adjust your settings and review each of your Canadian purchases to verify them. Yes, it’s tedious. Individual merchants have to decide what’s best for them.

  5. Nate on the 09. Dec, 2013 remarked #

    I guess I’ll have to do what I should have anyways, and create two separate steps for auth/capture process and evaluate AVS etc. on my own in between them. Thanks for the info. It’s incredible that Authorize.net won’t address these crucial issues after all these years, and doesn’t even seem to be aware of them.

Leave a Comment