Integration and Testing

[Michelle]

We have a new way of testing for transaction responses when using your test account that you can start using now, which includes the ability to trigger partial authorization responses. We're working on updating the documentation, but in the meantime, here you go!

In the following tables, the first column shows the value to use to trigger the response shown in the second column.

General Responses

ZIP CODE	RESPONSE CODE	RESPONSE TEXT	NOTES
46282	2	This transaction has been declined.	General bank decline

AVS Responses

ZIP CODE	AVS RESPONSE	AVS STATUS	NOTES
46206	P	AVS Not Applicable
46203	E	AVS data provided is invalid or AVS is not allowed for the card type that was used.
46207	R	The AVS system was unavailable at the time of processing.
46204	G	The card issuing bank is of non-U.S. origin and does not support AVS.	Not applicable to American Express
46209	U	The address information for the cardholder is unavailable.
46208	S	The U.S. card issuing bank does not support AVS.
46205	N	Address: No Match ZIP Code: No Match
46201	A	Address: Match ZIP Code: No Match
46217	Z	Address: No Match ZIP Code: Match
46211	W	Address: No Match ZIP Code: Matched 9 digits	Not applicable to American Express
46214	X	Address: Match ZIP Code: Matched 9 digits	Not applicable to Visa or American Express

CVV Responses

CARD CODE	CVV RESPONSE	CVV STATUS
900	M	Successful Match
901	N	Does NOT Match
904	P	Is NOT Processed
902	S	Should be on card, but is not indicated
903	U	Issuer is not certified or has not provided encryption key

Partial Authorization Responses

ZIP CODE	RESULT	REMAINING BALANCE	AUTHORIZED AMOUNT
46225	Partial Authorization	n/a	$1.23
46226	Partial Authorization	$1.23	Full amount
46227	Partial Authorization	-$1.23 (negative balance)	Full amount
46228	Partial Authorization	$0	Full amount

Thanks,

Michelle

Developer Community Manager

[oakleaf]

Hi,

I am using the methods in this thread to post a partial auth transaction.

AIM method
Amount: $295.00

Zip code: 46225

x_type = "AUTH_CAPTURE"

x_test_request = "false" (was not working previously when set to true)

Posting to: https://test.authorize.net/gateway/transact.dll

This was working perfectly on Friday (returning 1.23), but at the moment, I am getting an authorized amount of  "1..23" in the raw response.  Please note the dual decimal points. Can anyone else reproduce this or have a suggestion? If further information is needed, please let me know. Thanks.

[Michelle]

Hi there,

Are you still seeing this error? We haven't had any reports of similar errors and aren't able to reproduce it on our end.

Thanks,

Michelle

Developer Community Manager

[cptest1080]

I can get specific AVS testing responses by using the 'zip-code' but I can't get any card-code responses by using the 3-digit card-code for CVV testing???

The cvv response is always 'blank'.

I've made sure to not send an address or a zip-code thinking that may override but still no luck.

Any suggestions.

[Trevor]

If you are using AIM, make sure that you are setting the version to 3.1 either in the Merchant Settings or by submitting x_version=3.1

Version 3.0 of AIM was limited to only 38 fields, 3.1 expanded this to an indefinite number of fields with the CVV response in field 39.  Card Code Validation cannot be performed using version 3.0.

[cptest1080]

I'm sending x_version=3.1 but still BLANK CVVresultcodes with card code as 901 to produce an error.

field 39 ???

I'm receiving in XML and there is no 'field 39'.

//response/CVVResultCode  is still always BLANK.

[nexus]

I'm having a similar issue.  My address, cvv and expiration are being passed (I can echo them upon a successful transaction) but when I look up the transaction in my authnet account, it says CVV: Not Applicable and AVS: Not Applicable

Right now, I can enter a legitimate credit card with fake CVV and expiration and it still goes through as successful....

[nexus]

Ok, the reason why AVS and CVV is not applicable is because x_recurring_billing was set to true.

Recurring billing disables AVS.

I have to credit BobbySmith007 for the solution.

[tracent]

I've tried to test for declined transaction responses from AIM using both the 4222222222222222 credit card and the 46282 zip code value (independently and together) in the production environment with x_version=3.1 and x_test_request=TRUE.

Any request with the 4222 card yields an invalid card error; requests with a valid LUN card and the zip of 46282 yields an approved transaction.

Any ideas what I might be doing wrong?

[Michelle]

Hey tracent,

The zip code triggers only work when you are using the test environment. If you are using a production account, they won't work. Also, you need to make sure the 4222 test card you are quoting is only 13 digits. Any longer and it won't work. That test card will work in the test environment as well as the live one--but only in test mode on the live site.

Give it a try again using the fixes above and see if that works.

Thanks,

Michelle

Developer Community Manager