cancel
Showing results for 
Search instead for 
Did you mean: 

Using test card number and test decline zip results in approved transaction

Hi. I know something similar has been asked on a number of occassions but I can't seem to find any issue with what I'm doing. I'm using a sandbox account in live mode. I'm using a test CC number: 5424000000000015. I'm using a test zip code: 46282. When running a transaction, I expect it to be declined but it is approved. 

 

Here's is the request to create the customer payment profile:

 

 

<?xml version="1.0" encoding="utf-8"?>
<createCustomerPaymentProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
	<merchantAuthentication>
		<name>3xr3TpK9VZ</name>
		<transactionKey>xxxxxxxxxxxxxxxx</transactionKey>
	</merchantAuthentication>
	<customerProfileId>1504041103</customerProfileId>
	<paymentProfile>
		<billTo>
			<firstName>issue1346</firstName>
			<lastName>Authnet Dupes</lastName>
			<address>123 Fake St</address>
			<zip>46282</zip>
		</billTo>
		<payment>
			<creditCard>
				<cardNumber>542400xxxxxx0015</cardNumber>
				<expirationDate>2022-06</expirationDate>
			</creditCard>
		</payment>
	</paymentProfile>
	<validationMode>none</validationMode>
</createCustomerPaymentProfileRequest>

 

... that results in a successfully created profile...

 

 

<?xml version="1.0" encoding="utf-8"?>
<createCustomerPaymentProfileResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <messages>
        <resultCode>Ok</resultCode>
        <message>
            <code>I00001</code>
            <text>Successful.</text>
        </message>
    </messages>
    <customerProfileId>1504041103</customerProfileId>
    <customerPaymentProfileId>1503352673</customerPaymentProfileId>
</createCustomerPaymentProfileResponse>

 

 

... then when I transact using that profile, the transaction is approved while I expect decline due to the test card and test zip. Here's the request and response:

 

<?xml version="1.0" encoding="utf-8"?>
<createCustomerProfileTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <merchantAuthentication>
        <name>3xr3TpK9VZ</name>
        <transactionKey>xxxxxxxxxxxxxxxx</transactionKey>
    </merchantAuthentication>
    <transaction>
        <profileTransAuthCapture>
            <amount>249.00</amount>
            <customerProfileId>1504041103</customerProfileId>
            <customerPaymentProfileId>1503352673</customerPaymentProfileId>
            <order>
                <invoiceNumber>1</invoiceNumber>
                <description>7e2395eb-2ec7-11e8-b567-02613d0bd556</description>
                <purchaseOrderNumber>7</purchaseOrderNumber>
            </order>
            <recurringBilling>true</recurringBilling>
        </profileTransAuthCapture>
    </transaction>
    <extraOptions>
        <![CDATA[x_solution_id=AAA100304&x_duplicate_window=0&x_zip=46282&x_test_request=FALSE]]>
    </extraOptions>
</createCustomerProfileTransactionRequest>
<?xml version="1.0" encoding="utf-8"?>
<createCustomerProfileTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <messages>
        <resultCode>Ok</resultCode>
        <message>
            <code>I00001</code>
            <text>Successful.</text>
        </message>
    </messages>
    <directResponse>1,1,1,This transaction has been approved.,TNGAXS,Y,40011872606,1,7e2395eb-2ec7-11e8-b567-02613d0bd556,249.00,CC,auth_capture,issue1346,issue1346,Authnet Dupes,,123 Fake
        St,,,46282,,,,issue1346@example.com,,,,,,,,,,,,,7,F51CF5BE661CA435706C4BC46681D314,P,2,,,,,,,,,,,XXXX0015,MasterCard,,,,,,,,,,,,,,,,,</directResponse>
</createCustomerProfileTransactionResponse>
marcguyer
Contributor
3 REPLIES 3

Since the use of the old createCustomerPaymentProfileRequest is discouraged, I've refactored to start using createTransactionRequest instead partly with the hope that the new functionality will honor the test values and result in the expected decline result. Not so. Here are the latest requests/responses to create the customer payment profile with test CC (5424000000000015) and test ZIP (46282) and the new createTransactionRequest with response.

 

<?xml version="1.0" encoding="utf-8"?>
<createCustomerPaymentProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
	<merchantAuthentication>
		<name>3xr3TpK9VZ</name>
		<transactionKey>xxxxxxxxxxxxxxxx</transactionKey>
	</merchantAuthentication>
	<customerProfileId>1504059751</customerProfileId>
	<paymentProfile>
		<billTo>
			<firstName>issue1346</firstName>
			<lastName>Authnet Dupes</lastName>
			<address>123 Fake St</address>
			<zip>46282</zip>
		</billTo>
		<payment>
			<creditCard>
				<cardNumber>542400xxxxxx0015</cardNumber>
				<expirationDate>2022-06</expirationDate>
			</creditCard>
		</payment>
	</paymentProfile>
	<validationMode>none</validationMode>
</createCustomerPaymentProfileRequest>
<?xml version="1.0" encoding="utf-8"?>
<createCustomerPaymentProfileResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
	<messages>
		<resultCode>Ok</resultCode>
		<message>
			<code>I00001</code>
			<text>Successful.</text>
		</message>
	</messages>
	<customerProfileId>1504059751</customerProfileId>
	<customerPaymentProfileId>1503371415</customerPaymentProfileId>
</createCustomerPaymentProfileResponse>
<?xml version="1.0" encoding="utf-8"?>
<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
	<merchantAuthentication>
		<name>3xr3TpK9VZ</name>
		<transactionKey>xxxxxxxxxxxxxxxx</transactionKey>
	</merchantAuthentication>
	<transactionRequest>
		<transactionType>authCaptureTransaction</transactionType>
		<amount>249.00</amount>
		<profile>
			<customerProfileId>1504059751</customerProfileId>
			<paymentProfile>
				<paymentProfileId>1503371415</paymentProfileId>
			</paymentProfile>
		</profile>
		<solution>
			<id>AAA100304</id>
		</solution>
		<order>
			<invoiceNumber>1</invoiceNumber>
			<description>d95444b6-2f88-11e8-b567-02613d0bd556</description>
		</order>
		<taxExempt>false</taxExempt>
		<poNumber>7</poNumber>
		<customerIP></customerIP>
		<transactionSettings>
			<setting>
				<settingName>recurringBilling</settingName>
				<settingValue>true</settingValue>
			</setting>
			<setting>
				<settingName>duplicateWindow</settingName>
				<settingValue>0</settingValue>
			</setting>
		</transactionSettings>
	</transactionRequest>
</createTransactionRequest>
<?xml version="1.0" encoding="utf-8"?>
<createTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
	<messages>
		<resultCode>Ok</resultCode>
		<message>
			<code>I00001</code>
			<text>Successful.</text>
		</message>
	</messages>
	<transactionResponse>
		<responseCode>1</responseCode>
		<authCode>OAKCJW</authCode>
		<avsResultCode>Y</avsResultCode>
		<cvvResultCode>P</cvvResultCode>
		<cavvResultCode>2</cavvResultCode>
		<transId>40011915080</transId><refTransID/>
		<transHash>5C8E07DDB7F875B58000FEB8745FE38D</transHash>
		<testRequest>0</testRequest>
		<accountNumber>XXXX0015</accountNumber>
		<accountType>MasterCard</accountType>
		<messages>
			<message>
				<code>1</code>
				<description>This transaction has been approved.</description>
			</message>
		</messages>
		<transHashSha2/>
		<profile>
			<customerProfileId>1504059751</customerProfileId>
			<customerPaymentProfileId>1503371415</customerPaymentProfileId>
		</profile>
	</transactionResponse>
</createTransactionResponse>

 

Again, note that a test CC is being used with a test ZIP that should result in a decline (expected behavior) but it result is approved (actual behavior).

marcguyer
Contributor

This is exactly my problem as well.  I'm attempting to test the declined response but following the currently published guidance does not result in a decline response.  Has anyone found the combination of values to pass that actually elicits a decline to test with?

After countless hours of trial and error, I found that the usage of the recurringBilling flag:

 

<transactionSettings>
<setting>
<settingName>recurringBilling</settingName>
<settingValue>true</settingValue>
</setting>
</transactionSettings>

... precludes the use of error/decline simulation. In other words, using a test card and zip code in sandbox does not work if you set the recurringBilling flag. Fortunately, that flag is essentially useless in development so the workaround is likely viable long-term.