Reply
Highlighted
Member
Posts: 1
Registered: ‎03-25-2019

Testing error response zip codes in sandbox do not work correctly with a 0.00 amount

When testing specific error codes in sandbox we have found an issue where certain responses are incorrect if using a 0.00 amount.

 

An example is using zip code 46201 which should return AVS response "A".

 

With a 0.00 amount it returns AVS response "N", but anything greater than 0.00 it correctly returns AVS response "A".

 

This will be a problem for us as we are only pre-authorizing the card to validate CVV and AVS responses and do not wish to authorize any amount from our end.

Highlighted
Moderator
Posts: 102
Registered: ‎06-26-2018

Re: Testing error response zip codes in sandbox do not work correctly with a 0.00 amount

Hi kc-andrew

 

I apologize, but I don't quite follow your quandry. 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. The Testing Guide amounts are there to allow you to test that your application handles these responses the way you wish them to before going live. 

 

If I have misunderstood, please feel free to clarify. 

 

Thank you,

Elaine

Highlighted
Contributor
Posts: 14
Registered: ‎12-06-2019

Re: Testing error response zip codes in sandbox do not work correctly with a 0.00 amount

Hello, Elaine,

 

We are having a similar issue with the sandbox. I would think that the sandbox should mimic what would happen in the production environment, but that does not seem to be the case.

 

If I understand what you are saying, the sandbox does not deal with “real” dollars and cents, thus the sandbox will always return a value of N for the AVS response. As kc-andrew has shown above, zip code 46201 results in an AVS response of N, when the documentation reports that the result should be A.

 

However, he has also found that this is only true when submitting a dollar amount of $0.00. If you change the dollar amount of $0.01 then the sandbox returns A. So, your hypothesis that the sandbox always returns N is incorrect. I have also confirmed this finding. An AVS response is provided in the sandbox environment if a value of $0.01 is provided.

 

This presents a problem for us because we do not know how Authorize.net will behave in production. Our ultimate goal is to 1) Create a Customer Profile, 2) Create a Customer Payment Profile, and 3) charge the Customer Payment Profile.

 

Prior to creating a Customer Payment Profile, we want to ensure that the CVV and AVS match with bank records. Once we have a match for CVV and AVS, then we would like to use that Customer Payment Profile for all future transactions and not bother confirming CVV and AVS.

 

It seems strange that you would require a dollar amount when running a Validate Customer Payment Profile Request in the sandbox, but not in production. I would hate to maintain different functions depending on the production environment. I would like to have one function that is used in both production and staging environments so that we can run unit tests against code prior to deploying to production. This would lead me create one method that works in both the sandbox/staging and in production.

The one method would use a value of
$0.01 to generate an AVS and CVV response, then record that result. After the response has been recorded, we would void the $0.01 charge to overcome the sandbox limitation. That would happen regardless of production or staging. I think that means we would have to pay $0.30 per transaction to run this authorization or whatever fee the merchant account provider charges. It seems that it would be easier and more cost effective to provide an AVS response for $0.00 in both the sandbox and production environments.

 

Can you confirm these assumptions?