topic Testing Guide: zipcode for declined doesn't work in Integration and Testing

Testing Guide: zipcode for declined doesn't work

fifty-git — Tue, 17 Sep 2019 14:08:26 GMT

In the testing guide: https://developer.authorize.net/hello_world/testing_guide/

The zipcode for a declined transaction is: 46282

We are trying to test with CIM

Thanks,

Re: Testing Guide: zipcode for declined doesn't work

mmcguire — Tue, 17 Sep 2019 21:44:16 GMT

Can you confirm:

1. You are testing using the sandbox and not the live api endpoint

2. The 46282 zip code is either the billing address zip code in an existing customer payment profile or explicitly in the billing address as part of a createTransaction request. (Some more details on your work flow would help if these are not correct)

3. You are testing with a credit card and not an eCheck

Thanks!

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Fri, 06 Dec 2019 20:16:53 GMT

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.

Re: Testing Guide: zipcode for declined doesn't work

fifty-git — Fri, 06 Dec 2019 20:21:02 GMT

They don't seem to concerned about fixing this. I had to resort to getting a decline with the CVV of 901. But I wasn't testing for specific responses. I hope they pay some attention to this.

- Don

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Fri, 06 Dec 2019 20:38:15 GMT

That is a little frustrating. I would like to use the integrated fraud filters for both AVS and CVV instead of writing the code ourselves. PayPal (PayFlow Pro) has similar issues in their sandbox, but I was hoping that Authorize.net would have a better sandbox as the documentation is well written.

Generating a decline message seems to work with a CVV of 901, but I wanted to generate specific messages for errors that a user may come across related to AVS. I didn't want to do this in production with an actual credit card, but may have to resort to that if we can't get the development environment to behave as expected/documented.

I am not sure if the problem is because of our workflow, where we are trying to validate CVV and AVS at the time of payment profile creation instead of when a profile is charged. It doesn't seem to make sense to check for CVV and AVS every time a profile is charged. It seems this could be done once when the profile is initially created and once if the payment profile has been updated.

I wanted to offload the storing of PCI data and use Authorize.net profiles.

Re: Testing Guide: zipcode for declined doesn't work

fifty-git — Fri, 06 Dec 2019 20:46:43 GMT

We're using profiles as well. Sorry I can't look into this more for you, but here is an error code page I found useful: https://developer.authorize.net/api/reference/dist/json/responseCodes.json

It's been sometime since I had to work with this, but I feel your pain. The docs a very sub-par.

I wish I had more time to look into our solution but I'm buried. Maybe Monday.

- Don

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Fri, 06 Dec 2019 21:02:38 GMT

Thank you for sharing your findings. Did you rely on the error codes based on https://developer.authorize.net/api/reference/dist/json/responseCodes.json or did you build your own error handling?

I have set-up the Fraud Filters as Follows:

CVV Filtering to decline: N, S, and U results. P results will be held for review.
AVS Filtering to decline: B, E, U, S, and N
AVS Filtering to allow: R, G, A, Z, W, and Y

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Fri, 06 Dec 2019 21:49:55 GMT

One more follow-up to this conundrum, the CVV testing where:

900 generates: M
901 generates: N
904 generates: P
902 generates: S
903 generates: U

works as expected, so it looks like there seems to only be an issue with generating the expected results for AVS.

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Sat, 07 Dec 2019 00:15:29 GMT

I am not sure if this clarifies the issue, but according to this post: https://community.developer.authorize.net/t5/Integration-and-Testing/Testing-error-response-zip-codes-in-sandbox-do-not-work/m-p/67146/highlight/true#M40603

We do not have a 0.00 amount to generate an AVS or CCV response in Sandbox, thus this amount should always return an N AVS response.
This does not mean that in Production that would also be the case because in Production you are actually sending card data to a card issuer for authorization and validation of this detail, if provided, and it is returned in the authorization response.

It seems that the sandbox will only return Y or N for AVS testing, despite that the contradicting documentation.

I tried charging a profile $0.01 with the zip code of 46201 and did see that the Address Verification Status is returned as (A). So, it appears that you have to charge the profile an amount greater than 0.00 to get the proper response in the sandbox environment. Can someone from Authorize.net confirm this requirement?

This causes a different issue that I will have to think about further. I was not planning on asking the client for their CVV after the initial creation or update of the profile. However, if I plan to reject all orders without a matching CVV, then I would have to request the user to pass along the CVV at the time we plan to charge their profile, or remove that restriction in the fraud filter.

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Wed, 05 Aug 2020 00:18:26 GMT

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?

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Fri, 07 Aug 2020 17:09:31 GMT

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!

Re: Testing Guide: zipcode for declined doesn't work

dblaze — Sun, 09 Aug 2020 16:19:54 GMT

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 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.