Critical: OK is not reliable to check if a transaction was successful
Closed this issue · 3 comments
Your example code says in multiple places to check for "OK" in the resultCode to check if a transaction has been successful:
https://github.com/AuthorizeNet/sample-code-java/blob/master/src/main/java/net/authorize/sample/PaymentTransactions/ChargeCreditCard.java#L61
https://github.com/AuthorizeNet/sample-code-java/blob/master/src/main/java/net/authorize/sample/PaymentTransactions/ChargeCustomerProfile.java#L63
Below is a screenshot of an actual Authorize.NET decline response, triggered by sending the zip code 46282.
As you can see, resultCode is OK. But this transaction is declined.
This is a serious issue as if someone uses your sample code, declines will be processed as if they were successful. E.g. Orders could go through without payment.
What I've found is that its more reliable to check the responseCode instead (e.g. "2" for decline). This is how I worked around this issue.
It would be interesting to know if "OK" is intended to be there for declines, or is this a bug on the server side in Authorize.NET?
Hi,
Apologies for the confusion. The result code 'OK' and the message included "I00001" means that the request was processed successfully by Authorize.Net servers. (Explanation of I00001 response code)
You are correct in saying that result code does not completely capture the success of the transaction. But as I have stated, the result code shows you the success of the API request.
It is still good practice to check for the transactionResponse as well. This response is returned to you from the payment processor after processing your transaction request.
The error message which you are seeing ("Transaction Declined") comes from the payment processor. (Explanation of 2 response code)
If you test this scenario on our Sandbox environment, this testing guide will help you with various inputs. Our sandbox functions similar to the live payment gateway however sandbox transactions are not submitted to financial institutions for processing. Sandbox transactions will never actually process a payment.
For your final question, yes, it is intended for OK to be there for declines. If the request was sent to Authorize.Net servers, the corresponding transaction request will be sent to the proper processor and you will get a result from the processor. Your flow in Authorize.Net was successful.
The processor might have issues with your data but that is contained in the transactionResponse.
I suspected that this might be the case, with OK expected to be there for declines. It does result in an inconsistent message though.
Looking at your code, first you check for OK, then if getMessages() returns null, the code prints that the transaction is successful and the response code is printed. If there are messages the transaction failed. While that would work, this code is unclear and not very verbose.
You could make the code clearer by checking each possible transaction response code (1-4 with approved, declined, on hold etc handled separately) print what happened as well as additional messages if they exist.
The code would then be alot clearer to read and it would be obvious what is doing, developers could then decide how they want to handle each type of response.
Hi,
Thanks for the suggestion. We will take it into account for improving the experience of our developer community.
I'll be closing this issue for now. Feel free to open up new issues for any new doubts.