topic Re: Why is resultCode OK when an error exists? in Integration and Testing

Why is resultCode OK when an error exists?

topshot — Mon, 27 Jun 2016 16:12:17 GMT

I was rather surprised when I tried your sample code with a transaction that was supposed to fail and it still said Ok for the resultCode, which per your samples indicates a successful transaction, but in reality it fails. How the response should be handled from your C# sample:

            if (response != null && response.messages.resultCode == messageTypeEnum.Ok)
            {
                if (response.transactionResponse != null)
                {
                    Console.WriteLine("Success, Auth Code : " + response.transactionResponse.authCode);
                }
            }
            else if(response != null)
            {
                Console.WriteLine("Error: " + response.messages.message[0].code + "  " + response.messages.message[0].text);
                if (response.transactionResponse != null)
                {
                    Console.WriteLine("Transaction Error : " + response.transactionResponse.errors[0].errorCode + " " + response.transactionResponse.errors[0].errorText);
                }
            }

Thankfully AuthCode does return empty, of course, but it would never hit the error condition. I even tried your "Try It" tab on your website and it does the same thing as shown below (bold mine):

<?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">
  <refId>
    123456
  </refId>
  <messages>
    <resultCode>
      Ok
    </resultCode>
    <message>
      <code>
        I00001
      </code>
      <text>
        Successful.
      </text>
    </message>
  </messages>
  <transactionResponse>
    <responseCode>
      2
    </responseCode>
    <authCode />
    <avsResultCode>
      Y
    </avsResultCode>
    <cvvResultCode>
      P
    </cvvResultCode>
    <cavvResultCode>
      2
    </cavvResultCode>
    <transId>
      2260293952
    </transId>
    <refTransID />
    <transHash>
      D0D962E445A0D83B9FAE2FFFBC516D82
    </transHash>
    <testRequest>
      0
    </testRequest>
    <accountNumber>
      XXXX0015
    </accountNumber>
    <accountType>
      MasterCard
    </accountType>
    <errors>
      <error>
        <errorCode>
          2
        </errorCode>
        <errorText>
          This transaction has been declined.
        </errorText>
      </error>
    </errors>
    <userFields>
      <userField>
        <name>
          MerchantDefinedFieldName1
        </name>
        <value>
          MerchantDefinedFieldValue1
        </value>
      </userField>
      <userField>
        <name>
          favorite_color
        </name>
        <value>
          blue
        </value>
      </userField>
    </userFields>
  </transactionResponse>
</createTransactionResponse>

It seems rather disingenious to provide samples that would act in this manner. We should be looking to see if AuthCode is not nothing to determine a successful transaction or not rather than an OK resultCode, but why is the resultCode OK in the first place when an error exists???

Re: Why is resultCode OK when an error exists?

RaynorC1emen7 — Mon, 27 Jun 2016 18:49:20 GMT

The first one is about if authorize.net process the transaction, which it did, that what the OK is for.

The second is the result of the transaction from the processor. Which was rejected with a response code 2.

Re: Why is resultCode OK when an error exists?

RichardH — Mon, 27 Jun 2016 19:19:31 GMT

Hello @topshot

We do plan to improve our sample code exactly as you describe and agree it is confusing.

Richard

Re: Why is resultCode OK when an error exists?

topshot — Mon, 27 Jun 2016 19:43:00 GMT

@RaynorC1emen7

Are there any cases where resultCode = ok but transactionResponse.responseCode would NOT be 1-4?

I assume if resultCode = error that transactionResponse.responseCode will be nothing and I know there must have been some kind of error.

My current test program has

        If response IsNot Nothing AndAlso response.transactionResponse IsNot Nothing AndAlso response.transactionResponse.responseCode = "1" Then
            Console.WriteLine("Success, Auth Code : " + response.transactionResponse.authCode)
        ElseIf response IsNot Nothing Then
            Console.WriteLine("Error: " + response.messages.message(0).code + "  " + response.messages.message(0).text)
            If response.transactionResponse IsNot Nothing Then
                Console.WriteLine("Transaction Error : " + response.transactionResponse.errors(0).errorCode + " " + response.transactionResponse.errors(0).errorText)
            End If
        Else
            Console.WriteLine("Error: no response from Authorize.Net")
        End If

What conditrions if any would that not catch?

Re: Why is resultCode OK when an error exists?

RaynorC1emen7 — Mon, 27 Jun 2016 19:57:06 GMT

As far as I know, if it is not I00001, it mean it failed something, which might or might not have any response code.

When it is I00001, it will always have response code 1-4.

But to be 100% sure, a mod can double check.

Re: Why is resultCode OK when an error exists?

Lilith — Thu, 07 Jul 2016 15:26:34 GMT

@RaynorC1emen7 is correct -- if, for createTransactionResponse, we return a value other than I00001, there may be no value for response.transactionResponse.responseCode at all.

(If you aren't setting this value to NULL before submitting createTransactionRequest, I'd recommend doing so, to avoid the potential of carrying forward previous values.)

But if we return I00001, there should be a value for response.transactionResponse.responseCode.

Technically, this could be a value between 1-4, but in practice, you should only expect three values:

1 = successfully authorized;
2 = declined (either by card issuer, or by ANet filters like AVS, CVV, or AFDS);
3 = error (either at processor level, or at ANet level)

A responseCode of 4 should be very rare, as these are internal to us and are usually transient.