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.

[RaynorC1emen7]

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.

What the stored procedure look like?

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.

It there a transactionID in the response when you get error 98?

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.

But the transactionID is from the transaction, so it is not there when you create the fingerprint.

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.

You mean the x_relay_response_url never get call? or are you doing something else?

[CC_WSP]

You mean the x_relay_response_url never get call? or are you doing something else?

In some cases yes.  I have 3 pages that handle the transaction:

1. Shipping & Billing page - collects the customer shipping and billing data.
2. Gateway page - validates the shipping & billing data, generates the fingerprint and sends the customer to the gateway
3. Receipt page - processes the data from Authorize.net and displays a receipt for the customer.

The logs clearly show the first two page loads.  In some cases the receipt page is loaded but the code provided by Authorize.net is 98.  Even though the logs show clearly that there was only one post to the gateway.  In these other cases we get an email that the script timed out but the logs have no entries that the receipt page was ever requested.

[RaynorC1emen7]

I'm still not clear what unique name do you use for your log as there is no transactionID until the receipt page. And I assume you always append to the log file.

[CC_WSP]

I'm still not clear what unique name do you use for your log as there is no transactionID until the receipt page. And I assume you always append to the log file.

The transactionID I was referring to is my own, not the one Authorize.net assigns to our transactions.  My website generates a transactionID as soon as a customer places an item in their shopping cart.  I use this transactionID as the filename for my log files to track the progress of the transaction through the checkout process.  

[CC_WSP]

I should add, about 98% of my transactions are successfully processed, or at least I receive the error code that the credit card is declined.  It is this 2% that is causing me grief with the code 98 or not loading the receipt at all.

[RaynorC1emen7]

I think it time to call support with your log info on code 98.

[CC_WSP]

I appreciate your time.  I am on the phone with support now.  I will report back when we find out the source of the problem.

Thank you.

[Trevor]

When you state that you are collecting the "Billing Information" on your site before directing to Authorize.Net, does this mean that you are collecting the card details as well? If you are, then it sounds like you may be using the DPM flow for SIM.  If this is the case, one possible cause of this is your customers using the back button if your relay response page is taking too long to load.

[CC_WSP]

one possible cause of this is your customers using the back button if your relay response page is taking too long to load.

We are collecting the credit card data just before sending the customer to the gateway.  When our customers use the back button the the log files clearly reflect this. 

But what we are mostly experiencing now is a "script timeout" message being displayed to the customer even though our receipt page is bot being requested.  In turn we receive a "Merchant Email Receipt" message from Authorize.net which includes our transaction details.

When I look up the logs for any of these transactions either the receipt page is never loaded or it is loaded and shows as a failed transaction code 98.

I have been logging these occurrences since last Tuesday:

Tuesday: 35

Wednesday: 14

Thursday: 12

Friday: 7

Weekend total: 2

Yesterday: 15

When we migrated to the new server we also changed IP addresses.  Until yesterday the instances of this problem steadily decreased.  My original theory was that Authorize.net has name servers that have cached our old IP address.  That would explain the "script timeout" messages since they failed to load the receipt.  That would also explain why I am not seeing logs to reflect the duplicate gateway submissions or the users' use of the back button.  But for name servers to cache an IP address for over 10 days would be very bizarre.

Support has escalated this to engineering as of June 14th but the engineer has not yet attempted to contact me regarding this ongoing problem.