Integration and Testing

[ddsbrian1]

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.

[ddsbrian1 · Accepted solution]

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

[ddsbrian1]

Any help on this would be greatly apprecieated....     

[RaynorC1emen7]

Is this a test transaction(testmode is on)? I don't think there is a way to test CAVV

[ddsbrian1]

No - we are definitely NOT in test mode.   The transactions that I am sending through with these variables are going through just fine.  

[RaynorC1emen7]

Then there should be a response from the response

for AIM field#40

http://developer.authorize.net/guides/AIM/wwhelp/wwhimpl/js/html/wwhelp.htm#href=4_TransResponse.htm...

[ddsbrian1]

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.

[ddsbrian1]

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!

[ddsbrian1 · Accepted solution]

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

[RichardH Administrator]

Thanks for your input.  I'll pass your suggestions on to the appropriate teams.

Richard

[jcleung13]

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?