SIM Reason Code 98: Due to duplicate fingerprint

[CC_WSP]

4 days ago we upgraded to a new server. Since then I am randomly receiving the response reason code of 98. I understand this means we are duplicating fingerprints. However I cannot see how this is possible. I am using a SQL table to insert records for each transaction and in turn using the identity column as my unique sequence number as part of my fingerprint. This number cannot be duplicated.

I am also logging every page load and writing troubleshooting data to the server hard drive so I can monitor the activity. The logs are stored using a unique transactionID as the filename. I have run test transactions to see if I can replicate this issue by using my browser's back button. I can reproduce the error 98 but the logs for my transaction clearly show the second submission to the Authorize.net gateway. As an additional safeguard to prevent duplication I have now also begun appending the transaction ID unto the unique sequence number before creating the fingerprint. I am still receiving these errors.

Also I am experiencing some transactions that are being sent to the gateway but my receipt page is never requested afterwards. I am hoping someone else may have experienced this and can help me identify the cause.

[CC_WSP]

I am very disappointed in the customer service regarding this issue.  This had been escalated to Engineering on 6/13/2012.  I was told I would hear from an Engineer within 24-48 hours.  I never heard back.  I called again on the 18th.  I was told again I can expect a call from an Engineer.  I called again today and was told this has now been escalated to the Products Department.  No correspondence whatsoever.  No notes from the Engineering department as to why it was escalated.

I can only speculate that they have discovered something wrong with the product and that is why it has been escalated.  Otherwise I should have heard from someone in Engineering to discuss my logs.

[CC_WSP]

I've finally gotten a communication with Jeremy O with customer service.  Here is his response:

-----Original Message-----

From: Authorize.Net Merchant Support

Sent: Thursday, June 21, 2012 10:19 AM

To: CC_WSP

Subject: x_relay_url coding (#8842-300716039-1196)

The reason why your customer's are being directed to the wrong website is because the coding is incorrect for the x_relay_url which is done in the coding as well as in the Account Settings page under response/receipt URL's.  CC_WSP needs to correct this coding in order for customers to be directed to the correct websites. 

The time out error is because the script is handling other information before it communicates with Authorize.Net.  The script must have Authorize.Net as the top priority in order to resolve the time out error. 

Thank you for contacting Customer Support.

Regards,

Jeremy O Authorize.Net Customer Support

-----/ Original Message-----

Here is my response to Jeremy:

Jeremy O,

We have not used the x_relay_url for many years.  At least since we implemented the Simple Integration Method.  We were instructed to instead use x_adc_url to store that value.  If the coding is incorrect then how is it possible that 95% of the transactions are successfully completed and the correct receipt is being displayed to the customer? 

The timeout error is triggered in many cases without any communication with our scripts.  Our scripts are programmed to collect the POST from Authorize.net and process it accordingly.  We have FREB logs on the server to indicate if this script fails.  The script also writes logs to the server hard drive so we can tell exactly where an error occurs in the event of an Authorize.net "script timed out" message. 

This coding has been in place for years.  It was not until our server migration on June 8th that these problems began occurring.  As I explained on my open ticket #1-42037237, it appears that you have name servers that have cached our old IP address which they are attempting to load our receipt.

Jeremy, I had begun this ticket on June 13th and escalated it to Engineering.  I was told by Authorize.net personnel that on the 19th the Engineering department escalated it to the Products department.  If what what you are saying is correct, why would the Enginieering department escalate this to the Products department?

I am willing to do a conference call at any time.  I will set aside everything to fix this issue. 

[Lilith]

I apologize for the miscommunication on this issue. Customer Support does not really have any way to have an engineer contact you about this issue--it is not a level of support we can offer as our engineers are focusing on maintaining current service levels and adding new services.

But since you say you are not reusing the fingerprint hash, I would like to know if you have tried setting up your code to display or log the values you're submitting for x_login, x_fp_sequence, x_fp_timestamp, x_amount, and x_fp_hash, just prior to the customer going to our Hosted Payment Form, to confirm that in fact you aren't resending it. RRC 98 is very specific, and while I understand your concern, there's no other condition that would cause RRC 98 save for a repeated fingerprint hash, so that must be our focus here.

[CC_WSP]

Hi Lilith,

I have added an XMLHttpRequest just as the gateway is loading to log the information being sent to Authorize.net and I am seeing duplicate fingerprints. 

I was just testing an order through my system and I reproduced the problem of Authorize.net not loading the receipt.

Here is the message that is being displayed instead:

An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

      This transaction has been approved.

It is advisable for you to contact the merchant to verify that you will receive the product or service.

I checked my logs in IIS and there was no corresponding request for my receipt made by Authorize.net for this transaction.  Every other instance of my receipt loading in the IIS logs show a status 200.

When I stated my logs show when a user uses the back button I was mistaken.  I used my back button and the script sent me back to the gateway and I received the code 98.  The IIS logs only show my initial loading of the gateway and then the second call to the receipt which logged the response code 98.

So the reason code 98 is just a symptom of the problem.  The main problem I am finding is the failure of Authorize.net to load the receipt.

[CC_WSP]

I have spent the last few days working with my hosting provider and they have been analyzing the traffic to and from our server.  They have confirmed that no traffic from Authorize.net was detected at the time when Authorize.net reports that "an error occurred."

[marcstraymond]

We just started experiencing the same problem CC_WSP describes...where the receipt page is seemingly randomly not being loaded and the following is shown to the customer:

An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card. 

      This transaction has been approved.

It is advisable for you to contact the merchant to verify that you will receive the product or service.

Most transactions get processed just fine, but every so often one encounters this issue.  The error email sent back notes that our "script timed out" - however, I've tested with forcing the receipt script to take at least 10 seconds to return a response, and transactions went through just fine...so a 'time out' doesn't seem to be the culprit.

[marcstraymond]

Apologies - turns out the issue was a problem in our script that was actually returning a 404 error.

[CC_WSP]

marcstraymond,

I'm curious, how would your script periodically return a 404 (file not found) error?

In my case the receipt is not even being requested or posted to.

Thank you,

CC

[CC_WSP]

This issue mysteriously stopped occuring on Friday 8/3/2012.  All transactions are now being completed with Authorize.net correctly requesting our receipt. 

[taers324]

If your Apply Pay supportted regions is ready to america, then you'll need to check with American Expresshere. Second, in case you are not signed into a checking out tool with an iCloud account that supports a sandbox user.