Verifying successful transaction

[RichardGrossman]

All of the sample code defines a successful transaction this way:

if response.messages.resultCode == MessageTypeEnum::Ok
      puts "Successful charge (auth + capture) (authorization code: #{response.transactionResponse.authCode})"

Another programmer where I #work claims that that only means that the AuthorizeNet server processed the request, and that to truly know that a transaction is successful you have to do this:

if @processor_response_raw.messages.resultCode == 'Ok'
    if @processor_response_raw.transactionResponse.responseCode == '1'

He claims that he has submitted a charge using the wrong zip code, and received a resultCode == 'Ok' but a responseCode indicating an error.

I bet him $1 that he's wrong.

[RichardGrossman]

Well he wins the dollar - the sample apps are all wrong. You can get "Ok" back as a resultcode on a failed transaction!

[brianmc]

I would say the answer is yes and no, I wouldn't give up the dollar quite yet either !

On CreateTransaction the top level error code does indeed indicate whether everything has gone ok on the Authorize.Net side. There are some cases where we return ok yet the inner response for example says the transaction is held for review by our fraud system. BTW An incorrect zip code will generally not be a decline from a processor (hence an OK for the transaction ) but rather go into one of our fraud buckets if you have AFDS settings enabled.

Much more common is the scenario where the outer error is E00027 (Transaction was unsuccessful) and the inner error gives a detailed explanation of the issue. See our response codes page: http://developer.authorize.net/api/reference/responseCodes.html

On the question of sample code I would say that they could definitely do more checking of the inner error codes (we'll work on that) however they are not wrong, as the line

puts "Successful charge (auth + capture) (authorization code: #{response.transactionResponse.authCode})"

would never print if there were not an Auth Code and that is the ultimate evidence of a successful credit card transaction.

Thanks again for the feedback, we'll try to convey the two error levels better in our CreateTransaction samples going forward.

Brian

[akankaria]

Hi @RichardGrossman , We have updated our sample codes (for all the languages) to demonstrate the various scenarios of response handling. For example, you can take a look at our charge a credit card sample @ https://github.com/AuthorizeNet/sample-code-ruby/blob/master/PaymentTransactions/charge-credit-card.rb

You can also use : http://developer.authorize.net/api/reference/dist/json/responseCodes.json to check for details about all the possible response/error codes to handle them appropriately in your code.

Let us know if anything is not clear.

[joshrieken]

We've been battling this issue as well.

When using the CIM API, we found that the resultCode can be 'Ok' and the responseCode can be 2. (This transaction has been declined.). We've had dozens of transactions come back like this over the last year or so.

So, now we're checking for responseCode != 1 as a failed transaction.

The new sample code does this:

if response.transactionResponse != nil && response.transactionResponse.messages != nil

Will that catch what we're encountering?

[akankaria]

Hi @facto,

Apologies for delay in response. Some other APIs result in response codes like '5' which essentially means need payer consent, and which is not exactly an error.

Moreover, response.transactionResponse.message is set only in case of successful transactions. So you can use if response.transactionResponse != nil && response.transactionResponse.messages != nil to check for successful response.