Integration and Testing

[dblaze]

It has been 8-months since I have had a moment to revisit this problem. It does not look like anyone from Authorize.net has responded and I don't see any responses to this thread. I am still running into the same issue where according to the testing documentation: https://developer.authorize.net/hello_world/testing_guide.html, using the zip code 46201 should generate a Visa AVS response of A, but  I am still getting No match on Street and Zip (N).

The response I received from the test gateway is: 
private 'validationDirectResponse' => string '2|2|27|The transaction has been declined because of an AVS mismatch. The address provided does not match billing address of cardholder.|A8D1IP|N|40052956153|none|Test transaction for ValidateCustomerPaymentProfile.|0.00|CC|auth_only|10174|Fgfwtleo|Shark Laser||1234 Wrightwood Ave|Los Angeles|US-CA|46201|US| 1 5555555555||fgfwtleo@sharklasers.com|||||||||0.00|0.00|0.00|FALSE|none||M|2|||||||||||XXXX4101|Visa|||||||0DQP2QCTE7OMWQOAQ9J6I0R||||||||||' (length=443)

Do I need to use a nominal dollar amount, such as $0.01? How are other developers working in the sandbox?

[dblaze]

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!

[dblaze]

tl;dr:

• Generate Failing AVS: 46205 (N)

• Generate Passing AVS: 46214 (Y)

• Don’t use 46201 (A) to generate a Passing AVS – Doesn’t work consistently

• Do use a valid (real) Zip Code to generate a valid AVS

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 reliable with a failing CVV than if you try to only set the AVS response to a failing zip code such as 46208 and 46205.

I have found that if you trying to generate a failure on AVS alone, the zip code 46205 seems to generate failures the most consistently. I have unit testing set-up to test failing AVS with 46205 and it seems to work all the time. 46205 will generate an N.

If you want to generate a passing AVS value and must use the Authorize.net zip codes, use 46214. This will give a value of Y. The documentation says it will generate an X, but I can’t seem to replicate that on a regular basis. You can also just use a valid zip code like 90210 or 33162. Valid zip codes seem to always pass.

As far as trying to generate an AVS result of A with 46201, I wouldn’t hold your breath. I couldn’t get Authorize.net to generate this response consistently.

I am done with this topic. I hope this helps someone else. It was a pain to figure out.