I have finally received a response from Authorize.net and the issue is being escalated. I have been able to get the sandbox to provide intermittent valid responses based on the testing guide if I use any Discover card that passes Lunh validation. I would say that I am receiving meaningful responses and it it is adequate to continue building the payment component of our website, but it does not seem to provide 100% accurate responses.
According to Authorize.net:
“We are happy to see that you are getting the correct response when using a Discover card. I went through each Transaction ID you provided and everything looks good in regards to the testing as you mentioned. I think it would be safe to say you are good to continue your testing with the Discover Cards and it will give you the correct response for testing purposes.”
I have found that the CVV responses work 100% of the time, which is nice. So if you are trying to generate a failure, I suggest that you set the CVV to a value of 901. For whatever reason, the AVS response is more accurate with a failing CVV than if you try to only set the AVS response to a failing zip code such as 46208 and 46205. The AVS seems to pass if the CVV is set to 900 regardless of the value of the failing zip code entered. Though this is not true 100% of the time. It does appear that 46208 and 46205 (failing zip codes) provide more reliable responses than simply trying to generate a passing AVS response by entering 46201 in conjunction with a failing CVV such as 901.
If you are trying to get an AVS response to fine tune the error message you display back to the user, the responses seem to be serviceable, but you have to combine the AVS Responses with CVV failures. This may or may not be the case in production. I hope that the production environment provides reliable AVS response codes, so that we can alert clients when their AVS information does not match what is on file with their financial institution.
Generating random Discover credit cards, will cause another issue that Authorize.net has yet to address, 19-digit credit card support, outlined in this Authorize.net post. Make sure to only use 16-digit credit cards or you will get:
'The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:cardNumber' element is invalid - The value XXXXXXXXXXXXXXXXXXXXX is invalid according to its datatype 'String' - The actual length is greater than the MaxLength value.' (length=212)
I am not sure how I will deal with that problem, but one disaster at a time.
I hope this helps!