Showing results for 
Search instead for 
Did you mean: 

SiM - Error 99

Hey everyone,


I am having a small issue.  I am using a SiM account and I downloaded the test code from's site.  It works just fine if I enter in a static $ amount for x_amount. 


However, when I try to pass a vaule via the web to it, it gives me an error 99.  Can anyone help me with this?





Hi Joe,


Thanks for joining our community! To answer your question, an error 99 occurs when the payment gateway cannot authenticate the transaction fingerprint submitted for your SIM transaction. So basically, the transaction fingerprint recreated by the payment gateway does not match the transaction fingerprint being submitted in x_fp_hash.


For security reasons, SIM requires the generation of a fingerprint hash, based on five values: amount, API Login ID, Transaction Key, timestamp and sequence number. If there are any issues with one of these values or the generation process, you will see an error 99.


The most likely causes you should look for are:

1) The Transaction Key that you have embedded in your script is not correct. Just to be sure, generate a new transaction key, disable the old transaction key, and enter the new value in your script and test the connection.


To obtain the Transaction Key:

1. Log into the Merchant Interface at

2. Click Settings in the main left side menu.

3. Click API Login ID and Transaction Key.

4. Enter your Secret Answer (the answer to your Secret Question configured at account setup).

5. To disable the old transaction key, click the check box labeled Disable Old Transaction Key
(Note: If the Disable Old Transaction Key check box is not selected, the old transaction key will automatically expire in 24 hours.)

6. Click Submit to continue. Your new Transaction Key is displayed.

You need to be sure to have your API Login ID and Transaction Key set in your scripts. When using PHP and ASP sample scripts, these fields must be filled out in your simdata.php or simdata.asp file, respectively. In the PERL sample script, it must be entered into the script.


2) The amount has to be set in your scripting prior to the generation of the fingerprint hash. This usually means that the amount should be set in a previous form and posted to the script that generates the fingerprint hash.


3) You may not be properly posting all the required fields for SIM.

All of the following fields must be present in your payment form request in order for the transaction to be accepted:

1. API Login ID (x_Login)
2. The sequence number of the transaction (x_FP_Sequence)
3. The time when the sequence number was generated (x_FP_Timestamp)
4. The Fingerprint Hash (x_FP_Hash)
5. The amount of the transaction (x_Amount)

4) If you are attempting to pass the field x_currency_code with your payment form request, you must include this field in your fingerprint hash generation. Since Authorize.Net currently handles transaction amounts in US Dollars only, you could also just stop passing x_currency_code.


You can also check out our error 99 resolution tool at for more troubleshooting help.


Hopefully this helps! Let us know if you were able to figure out what the problem was.


Thanks again,



You need to trim the amount field, there is probably a white space (CR or new line) at the end. Note I observe this problem with IE, but it does not happen in Firefox


Look it is not enought to repeat your manual. These people are smart and can read it. This problem happens with IE when there is white space at the end of the x_amount field. This is why he has the problem for non-static values, for static dollar amount, he has no problem (hence don't read him your manual). He probably has a drop down list and the amounts in the drop down were stored as white space separated list ( CR, NL, Blank ). In IE, his code get the extra- white space as part of the amount input, in Firefox, the white space is removed. When the info is posted to the website, you code is hashing the x_amount field without the white space.


He need to trim the white space and then do the hashing thing, trim(x_amount). By the way, Firefox takes care of the trimming.


I had the same problem and the trimming made it go away. You can also do "view source" in both IE and Firefox and observe the extra white space from IE, when you have a list separated by CR or new line


I was unable to find posts with error 99 where the fingerprint matches. In my situation I was able to duplicate their generated fingerprint (using the 99 tool) with my generated fingerprint. I checked for whitespace and there was no issue there. The representative had me change the case of the amount variable from x_Amount to x_amount as well as generating a new transaction key. I also verified that our server's time was no more than a second behind real time. Nothing would alleviate the error.


This issue is intermittent as I can see other transactions being processed while I still get error 99. Any insight would be appreciated.

Hi Justin,


I'm confused as to why you are certain that the fingerprint matches, since the error 99 only occurs when the fingerprint value that you submit does not match the one that is generated in the Authorize.Net system. Since you don't know what fingerprint value that is, I am unclear why you believe that it matches. I can only guess that you are assuming that it matches becuase the generation of your fingerprint value using the Error 99 Tool on the developer center matches what you are submitting with your transaction(s). This does not mean that the value you are generating is correct as far as what should be submitted, it only means that your code is generating your fingerprint value correctly as far as how you are telling it to. Generally, if the Error 99 Tool generates the same value that you are submitting, yet you are seeing an error 99, it indicates that the values which you are using to generate the fingerprint value are not the correct values that should be used, such as when you include the x_currency_code value pair in your POST but do not include this value in the generation of your fingerprint value. If this does not help you clear up the error 99 that you are seeing please send all of the details of what you are sending and seeing in response to, but please make sure to mask any secure data as email is not a secure form of communication.



Thank you,



Trusted Contributor
Trusted Contributor

 I'm having the same basic problem, and I even went to the Response Code 99 Tool page and generated the fingerprint, which matches the fingerprint from my system exactly.

 Is there something I need to fill in here that I'm overlooking?



 echo '<form method="post" action="">';
                    echo '<input type="hidden" name="x_login" value="'. $api_login_id .'" />';
                    echo '<input type="hidden" name="x_fp_hash" value="'. $fingerprint .'" />';
                    echo '<input type="hidden" name="x_amount" value="'. $amount .'" />';
                    echo '<input type="hidden" name="x_fp_timestamp" value="'. $fp_timestamp .'" />';
                    echo '<input type="hidden" name="x_fp_sequence" value="'. $fp_sequence .'" />';
                    echo '<input type="hidden" name="x_version" value="3.1">';
                    echo '<input type="hidden" name="x_show_form" value="payment_form">';
                    echo '<input type="hidden" name="x_test_request" value="false" />';
                    echo '<input type="hidden" name="x_method" value="cc">';
                    echo '<input type = "image" src="images/Checkout-Button2.png" />';
echo '</form>';


the only thing I could think of is to check the web browser page source on your form post page to make sure everything is correct, no extra space in the values, 2 decimal for the amount, etc.

 I've checked that, plus I had to input that same informaton into the Response Code Tool remember, so if something was amiss, it should have shown up there first.


 Does the x_test_request" value=" need to be set to TRUE or do any of the other hidden fields need to changed from their default values found on the sample code page?


Usually is typo on something. but if  you checked the page source and you are only using those post fields.

The only thing that I could think of is the transactionkey somehow got change on the merchant account settings, regenerate it.