I am running into a similar issue. I can't seem to generate the anticipated errors outlined in the testing manual: https://developer.authorize.net/hello_world/testing_guide_new/
Our submitted transactions to the Sandbox with the zip code 46282 results in an approval, not a decline.
I am creating a payment profile and running setValidationMode to generate DirectReponseList. I am storing the results of the Address Verification Status and Card Code Status in MySQL. If the payment method passes AVS and CVV, then I won't bother checking those values when we charge the client's stored profile on Authorize.net. If they do not pass, then I need to let the client know what they need to do to fix the error. I want to decline any submission with No Match on CVV, but would be willing to allow a client through if AVS fails in certain situations.
However, using the provided zip codes to simulate AVS failures or General failures doesn't always correlate to what is documented. For instance, using zip code 46208, I would expect to receive an AVS Response of S, but instead receive X (40041694980). I have a similar issue with 46207, which should give an AVS Response of R, but instead results in X (40041695215). I have a similar issue with 46201, which should give an AVS Response of A, but instead yields N (40041695627). Using the zip code 46211 generates a code of Y, which I would have expected W (40041695768).
This isn't always the case, when using 46205 I am expecting to receive AVS Response of N, which is what I receive (40041695465).
Credit Card: 6011000000000012
CVV: 900
I am trying to give the user useful instruction of how to correct AVS errors, but cannot do that without a reliable test environment to simulate the errors.