We have recently signed on with Cardinal Commerce to provide authenication services. We are fully integrated with them and able to receive back an ECI and CAVV.
We are then including these values in our tranasction post to ANet as the x_authentication_indicator and x_cardholder_authentication_value respectively.
We've confirmed via the Data Validation tool that these are being interpreted as expected.
When we check the transaction detail in ANet - we are seeing:
CAVV Result Code: Not Applicable
How can we determine if the data we are posting is being received properly?
(Phone and Live support was not able to tell us this and recommended we post here).
Note that we are simply including these variables in our transaction post string like:
&x_authentication_indicator=5&x_cardholder_authentication_value=AAABCRiYlnA1JngDZpiWAAAAAAA%3D
Please help.
Thanks!
Brian D.
Solved! Go to Solution.
03-04-2013 09:12 AM
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:
40 | Cardholder Authentication Verification Response | Value: The cardholder authentication verification response code Format: Blank or not present = CAVV not validated
|
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
03-15-2013 10:50 AM
Any help on this would be greatly apprecieated....
03-05-2013 01:51 PM
Is this a test transaction(testmode is on)? I don't think there is a way to test CAVV
03-05-2013 02:11 PM
No - we are definitely NOT in test mode. The transactions that I am sending through with these variables are going through just fine.
03-05-2013 03:08 PM
Then there should be a response from the response
for AIM field#40
03-05-2013 03:26 PM - edited 03-05-2013 03:26 PM
That field is returning as blank.
I learned some new information today that is likely the cause of this issue. The Merchant Processor (Transfund) is not set up to handle this on their end. I was led to beleive they were. I'm hopeful that is the cause of this issue and will lead to a speedy resolution.
Should this turn out to be the cause - then I suggest that Authorize.net work on updating their response codes to give some information when this type of situation occurs. An error in the 40th field of the response would have helped immensely in confirming that the data was posting and that there was a problem on the processor end.
Please consider this for future updates.
If this turns out NOT to be the problem - I will follow up here.
Thank you for your assistance.
03-06-2013 09:19 AM
The merchant account company has (claimed they have) made the changes needed for this to work. We've tested again - and are seeing the same (lack of) results.
The 40th field in the response being blank in every case is what is really confusing me. It seems based on the TransResponse file you sent over that we should be getting SOMETHING back - even if it's an error.
In an effort to get to the bottom of this - here is everything we are posting, and the responses we are getting back. I've X'd out or removed the sensitive information.
We are posting to:
https://secure.authorize.net/gateway/transact.dll
Post Data:
x_Version=3.1&x_Delim_Data=True&x_Login=XXXXXX&x_Amount=46.25&x_Card_Num=XXXXXXXXXXXXXXXX&x_Exp_Date=XXXXXX&x_Address=XXXXXXX&x_Zip=XXXXX&x_first_name=XXXXX&x_last_name=XXXXXXX&x_city=San Diego&x_state=CA&x_country=US&x_phone=XXX-XXX-XXXX&x_email=XXXXX@XXXXXX.COM&x_Type=AUTH_CAPTURE&x_Invoice_Num=338302&x_tran_key=XXXXXXXXXXXXXXXX&x_authentication_indicator=05&x_cardholder_authentication_value=AAABAIVCIhAJQDJRU0IiAAAAAAA%3D&x_card_code=XXX&x_description=URL.com+Order(https://www.URL.com)
Response:
1,1,1,This transaction has been approved.,033259,Z,5067286049,338302,URL.com Order(https://www.url.com),46.25,CC,auth_capture,,XXXXX,XXXXXX,,XXXXXXX,San Diego,CA,XXXXX,US,XXX-XXX-XXXX,,XXXXX@XXXXXXXX.com,,,,,,,,,,,,,,25F7B33C8F919242B3EF15FAD8C5C1A1,M,,,,,,,,,,,,XXXX3770,Visa,,,,,,,,,,,,,,,,
So - we are posting the fields - but getting nothing in the response.
Please help!
03-07-2013 11:47 AM
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:
40 | Cardholder Authentication Verification Response | Value: The cardholder authentication verification response code Format: Blank or not present = CAVV not validated
|
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
03-15-2013 10:50 AM
Thanks for your input. I'll pass your suggestions on to the appropriate teams.
Richard
03-15-2013 11:03 AM
I am having the same issue and was wondering if you could elaborate on getting my account reset?
Are you talking about your authorize.net merchant account and did you need to give or your processor them any special instruction?
05-02-2013 12:53 PM