To put some closure to this issue - we believe we have figured it out.
The merchant account was not set up properly. It was initally set up not intending to work with Authorize.net - yet it still worked with authorize.net. We're not entirely sure how that would have happened - but it's something on the processor side.
They ended up setting up a whole new account that was correct from the ground up and seemed to solve the problem.
I do have a suggestion for Authorize.net. One primary source of frustration in this adventure was that we were not getting any response back when we expected one in the CAVV Result Code field. According to your own documents:
http://developer.authorize.net/guides/AIM/wwhelp/wwhimpl/js/html/wwhelp.htm#href=4_TransResponse.htm...
40 | Cardholder Authentication Verification Response | Value: The cardholder authentication verification response code Format: Blank or not present = CAVV not validated ■ | 0 = CAVV not validated because erroneous data was submitted |
■ | 1 = CAVV failed validation |
■ | 2 = CAVV passed validation |
■ | 3 = CAVV validation could not be performed; issuer attempt incomplete |
■ | 4 = CAVV validation could not be performed; issuer system error |
■ | 5 = Reserved for future use |
■ | 6 = Reserved for future use |
■ | 7 = CAVV attempt – failed validation – issuer available (U.S.-issued card/non-U.S acquirer) |
■ | 8 = CAVV attempt – passed validation – issuer available (U.S.-issued card/non-U.S. acquirer) |
■ | 9 = CAVV attempt – failed validation – issuer unavailable (U.S.-issued card/non-U.S. acquirer) |
■ | A = CAVV attempt – passed validation – issuer unavailable (U.S.-issued card/non-U.S. acquirer) |
■ | B = CAVV passed validation, information only, no liability shift |
|
It seems that since we were posting the fields - we should have gotten back a 0. Or perhaps you need a new response showing that you received the info, but did not get any response from the processor.
If you want more details about this - ask.
Thanks.
Brian
