Integration and Testing

[fifty-git]

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,

D

[mmcguire]

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!

[dblaze]

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.

[fifty-git]

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

[dblaze]

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.

[fifty-git]

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

[dblaze]

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

[dblaze]

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.

[dblaze]

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

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

[Denial]

Thanks For It

Visit Now: https://elogin.online/