You are viewing limited content. For full access, please sign in.

Question

Question

Authorize.Net payment went through but response code was declined

Forms Version 11
Updated September 18, 2024
asked on September 18, 2024 • Show version history

We have been using Authorize.Net to process payments with Laserfiche Forms for about 20 months now. This is the first time this has happened, but due to the nature, we feel we need a solid answer.

Last week a payment was processed, the response we received for the transaction was a code 6 indicating that the card declined due to an invalid card number being used. We have an email notification set up to email our taxpayer to let them know if the payment they made was a success or failure. She received the failure email and called her bank. The bank told her the payment went through. She called the Treasurer's office to inform them. The next day the Treasurer's office received the settlement batch report from Authorize.Net. The settlement report showed that transaction did go through. 

In the forms instance monitor screen, the following message appears in the instance history; Transaction details cannot be accessed because the transaction detail API is disabled on Salem LF Payment Gateway2. [See screenshot below] We did not ever disable this, it is not currently disabled, and transactions since this one have gone through without issue. I sent an email to Authorize.Net and their answer to me is that we need to generate a new Transaction Key in Authorize.Net and update it in our LF server. We researched this and found that best practice is to generate fresh codes every year, similar concept to updating passwords. We intend to do this and make it a regular practice. This does not answer the question though. If that were the issue, it does not explain a response that the card was declined due to an invalid card number or that other transactions since are going through.

Has anyone else experienced this? Any ideas on what the cause of this might be? The server Event Viewer does not show any errors at the time this transaction occurred. 

0 0

Replies

replied on September 18, 2024

I can't speak to the exact issue because I haven't used the built-in Authorize.Net integration, however, I have dealt with Authorize.Net and I can say that sometimes things do go wrong on their end.

It has been very rare, but over the years I have had a handful of scenarios in which the response I got from the Authorize.Net API suggested a transaction failed when it actually went through.

It is unlikely that Laserfiche Forms just "applied" the wrong response code, so based on my experience I'd expect that it just received bad data from Authorize.Net on this one.

1 0
replied on September 18, 2024

Concerning! I am glad the taxpayer called her bank instead of assuming this was a correct response and paid again. We could refund the money, but it would not leave a good impression. And then there is the possibility of the second transaction causing overdrafts and all that comes with that.

It sounds like we will just have to hope it doesn't happen again but expect that it will. I'm glad, at least, that your experience with this issue has been "very rare". Thank you for your response! 

0 0
replied on September 18, 2024

Hi Vikki,

Our Fiscal department keeps a pretty close eye on things, so the few times it did happen we caught it pretty quick since things didn't balance out. I highly recommend running reports to compare the numbers coming out of Forms and make sure they match up with the settlement batches.

Credit card processing has a lot of moving parts since the transactions also have to go from the Authorize.Net gateway to the actual payment processor, so we try to keep close tabs. As you know those rare 0.01% errors can still be a problem when you're dealing with financials and credit card payment, so it's better to stay ahead of it rather than risking chargebacks and such.

0 0
replied on September 18, 2024

We do provide a report for their office to balance to the settelement batch report from Authorize.net, however, that check is made every morning for the transactions the previous day (settlement batch report is only provided once daily). In a case like this, the taxpayer could easily have paid again right after getting the response the payment failed. 

1 0
replied on September 18, 2024

The error in your screenshot states that since the API was disabled at that time, the transaction details could not be retrieved. If the API was down, how could you get a response that the card number is invalid? Based on the error in your process it just looks like the transaction details were not available while the API was offline, not that it did not go through. You can't disable the API, your the one calling the API, Authroize.net is the one who disabled it (likely for a maintenance window)

0 0
View 2 previous replies
replied on September 18, 2024

That does make sense as far as the error in the instance details. If they disabled it, though, we were not provided that information ahead of time or after asking about this issue.

This is the exact response we received from Authorize.Net (see below). They sent back a code 6, and code 6 is Invalid Card Number. We actually can disable/enable the Transaction Details API in our settings menu. We didn't though, no one with access to this setting had logged in to our account. 

 

0 0
replied on September 18, 2024 • Show version history

Yea, you would not have received a transaction id if their API was offline/unresponsive; this seems more like the (rare) false negatives I've seen before, and those happened entirely separate from Laserfiche.

1 0
replied on September 18, 2024

Ah then it likely suspended and retried once the API was online.

 The next day the Treasurer's office received the settlement batch report from Authorize.Net. The settlement report showed that transaction did go through. 

I would pull up the transaction details on Authroize.net for this ID and ask them why it is showing a 6 in the transaction code. Unless your saying on their website, it does not show a 6. I doubt Laserfiche just made that number up.

0 0
replied on September 18, 2024

The website matches the settlement batch and shows successful.  

0 0
replied on September 18, 2024

I think Jason might be right, they might be flipping numbers on you, thankfully you have the track tokens to verify it returned a 6 at the time. It is really odd that you got an error about the API being offline with the same transaction, something unusual was happening at that time but your captured the code 6 response so someone must have changed it after that.

Maybe they have a system that keeps retrying and it eventually succeeded. Like in the case where you have to respond YES to a text on your phone from your bank before it goes through.

0 0
replied on September 18, 2024

We do provide a report for their office to balance to the settelement batch report from Authorize.net, however, that check is made every morning for the transactions the previous day (settlement batch report is only provided once daily). In a case like this, the taxpayer could easily have paid again right after getting the response the payment failed. 

You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...