Payment Error Codes

For American Express call: (800) 528-2121
For Diners Club call: (800) 525-9040
For Discover/Novus call: (800) 347-1111
For JCB call : (800) 522-9345
For Visa/Mastercard call: (800) 228-1122

Once an authorization is issued, you can then submit the transaction through your Virtual Terminal as a Capture Only transaction.

The fields that are validated include:

If any of the fields change from one transaction to the next, Authorize.Net will not view the transactions as duplicates.
The duplicate transaction window will always be two minutes for all transactions submitted through the Virtual Terminal. If you wish to adjust the duplicate transaction window for transactions submitted from your software, such as a website or shopping cart, you may do so by adding the field duplicateWindow to your website script.
If you are unable to adjust or add this variable to your shopping cart settings, please contact your shopping cart support team for additional assistance in this regard. The variable duplicateWindow tells us, in seconds, how much time we should check for duplicates after a transaction is submitted.
The largest value we will accept for duplicateWindow is 28800, which equals eight hours. If a value greater than 28800 sent, the payment gateway will default to 28800. If duplicateWindow is set to 0 or to a negative number, no duplicate transaction window will be enforced for your software’s transactions. If no value is sent, the default value of 120 (two minutes) would be used.
For example, if you wished to set a duplicate transaction window of five minutes (= 300 seconds) you would set duplicateWindow to 300.
Note: By submitting duplicateWindow with your online transactions, we will return further details along with this error response, including:

• The original transaction ID that was duplicated;
• AVS and CVV responses for the original transaction;
• The original authorization code, if the transaction was authorized;
• The MD5 hash, if a MD5 hash value was generated for the original transaction.

If you do not submit the duplicateWindow field, we will not return any details from the original transaction, even if you submit a duplicate transaction.

• If you are posting your transaction requests to the gateway URLs https://test.authorize.net/gateway/transact.dll and you are using an account given to you by an Authorize.Net Reseller or from Authorize.Net Sales, you may encounter this error. The gateway URLs mentioned above only work with specific test accounts, available upon request by completing the form at https://developer.authorize.net/hello_world/sandbox/
• Please check your script and verify you are posting the API Login ID for the account in question. If you are not posting the correct API Login ID, or if you are not sending an API Login ID, please edit the script and confirm that the field name is set to the API Login ID that you may obtain from the Authorize.Net Merchant Interface. Please see the Getting Started Guide at https://www.authorize.net/content/dam/authorize/documents/gettingstarted.pdf for instructions on obtaining the API Login ID.
• If you are unable to log into your Authorize.Net Merchant Interface, this could indicate that your account is inactive. Please contact Merchant Support for assistance.
• If the account is active and the API Login ID is correct, please use the Data Validation Tool to validate the fields you are passing to us.

• Login to your Merchant Interface at https://account.authorize.net/</a
• Click Settings in the main left side menu
• Click Response/Receipt URLs
• Click Add URL
• Enter your Response URL
• Click Submit

To change the field value to not required:

• Login to your Merchant Interface at https://account.authorize.net/</a
• Click Settings in the main left side menu
• Click Payment Form
• Click Form Fields
• Uncheck the field provided in the Error 33 text.
• Click Submit

• Check that your script permissions are correct and that it can accept an HTTPS POST.
• Check that the script is not completing other functions before writing to the screen, such as writing to a database or sending emails.
• Please check to see if there are different processes that are used in your script for approvals, declines, or errors. Check each process to be sure that they will write to the screen before any other functions.
• Check if your script is using redirects immediately upon receipt of the response from our servers. Redirects are discouraged because they can potentially interfere with the process.

On occasion, timeouts will occur that are outside of the control of your script or our servers. Typical reasons for these timeouts include Internet traffic, your server is overloaded or malfunctioning, or Internet routing issues. Depending upon your server location and what route is used to send data, it is possible that you may occasionally receive the message you are seeing.

• Login to the Merchant Interface at https://account.authorize.net
• Click Merchant Profile in the main left side menu
• Click Edit Business Information
• Update your Address, Phone Number, Fax Number, Products/Services Description, Web Site Address, and Shopping Cart Solution as necessary.
• Click Submit
• Click Continue to return to the Merchant Profile page.

If the Merchant Profile has your correct address-including the country-then you may need to contact your Merchant Service Provider to confirm that TSYS/Vital/Visanet has the correct address for validation.

• • The sequence number of the transaction (x_fp_sequence)
  • The time when the sequence number was generated (x_fp_timestamp)
  • The Fingerprint Hash (x_fp_hash)

“

• Login to the Merchant Interface at https://account.authorize.net/
• Click on Settings
• Click on Direct Response
• Change Delimited Response to “True”

3. Confirm that you are sending us the field x_delim_data, and that it is set to TRUE.
4. Also confirm that you are sending the field, x_relay_response, set to FALSE. Otherwise, we will attempt to use any default Relay Response or receipt links listed in your Response/Receipt URL settings in the Merchant Interface, which causes this error.
Simple Integration Method (SIM) Suggestions:
1. You will receive this error if there are variables being sent that are not applicable to SIM. Two of the variables that are most commonly incorrect include:
x_adc_relay_response – the variable name should be sent as x_relay_response
x_adc_relay_url – the variable name should be sent as x_relay_url.
2. You will receive this error if the proper fingerprint hash variables are not being sent with the transaction request. The variables that need to be included (with appropriate values):
x_fp_hash< x_fp_sequence x_fp_timestamp
These variables are used in creating and then passing the fingerprint hash with the transaction request. Authorize.Net then uses the passed variables and the stored transaction key to attempt to create the same fingerprint hash. If the two fingerprints match, we accept the transaction. If not, the transaction request is refused.
We highly recommend that you upgrade your connection method.
Please visit our Developer Center for up-to-date documentation.

• The amount of the transaction;
• A sequence number—usually an invoice number generated by your scripting, but can be randomly generated as long as it doesn't repeat;
• Your server's timestamp, expressed in Greenwich Mean Time (GMT) or Coordinated Universal Time (UTC);
• Your account's Transaction Key; and
• Your account's API Login ID.

Any fingerprint hash can only be used once in 24 hours.

If a customer fills in incorrect information and the transaction is declined, they cannot click Back and re-enter the information as this will attempt to use the same fingerprint hash in resubmitting the transaction request, which will result in error 98.

The customer must be directed back to the page that sets the amount of the transaction request, then re-enter information from that point on.

If you are receiving this error, it indicates that either x_password or x_tran_key is being submitted with your WebLink request. This represents a security risk as the password or transaction key could be viewed in your source code.

We highly recommend that you upgrade your connection method.

Please visit our Developer Center for up-to-date documentation.

• If you are using SIM, make sure you are using a valid transaction key to generate and send a fingerprint hash to us along with your transaction request.
• If you are using AIM please make sure you are posting the gateway defined field transactionKey.
• If you are using a third party shopping cart which uses AIM and are receiving this error, please check with your shopping cart provider to ask if your application can pass the transaction key to the Authorize.Net payment gateway.
• If you are using an older Authorize.Net account and you submit a password instead of a transaction key with your transactions, you may experience this error. Please ensure that you are posting a transaction key instead.
• Some shopping carts, for backwards compatibility with older connection methods, may provide the means to submit both a transaction key and a password. You should not use both the transaction key and the password simultaneously; doing so may also result in this error. We recommend using the transaction key instead of the password whenever possible, as transaction keys tend to be more secure than passwords. In such a situation, please leave the password field blankIf the shopping cart has a field for the password but no field for the transaction key, please put the transaction key in the password field. Our system will recognize and validate the transaction key properly.
  Also, while most shopping cart software will have a field for the transaction key, password, or both, some software may not. Please contact your shopping cart provider for details on how to upgrade to a more secure version of your shopping cart software.

• Chase Paymentech
• FDMS Nashville (formerly FDC)
• Global Payments (GPS)
• TSYS (formerly Vital)
• Wells Fargo (Verified by Visa only)

Also, this error can be received in the event that a special character is included in the cardholder authentication value. To resolve this issue, the special character must be URL encoded.

Also, verify that the merchant's processor supports Verified by Visa and Mastercard SecureCode authentication values through Authorize.Net.

• Chase Paymentech
• FDMS Nashville (formerly FDC)
• Global Payments (GPS)
• TSYS (formerly Vital)

• Log into the Merchant Interface at https://account.authorize.net/
• Click Settings in the main left side menu
• Click API Login and Transaction Key
• If an API login ID has already been generated, it will be visible here. If an API Login ID needs to be generated, you will want to enter the answer to your Secret Question in order to see the API Login ID.

• Set marketType to "0" to flag the transaction as e-commerce.
• Set transactionType to authCaptureTransaction or authOnlyTransaction.
• Specify both opaque data parameters.
• Do not include card number, expiration date, or track data.
• Do not include 3DS data.
• Ensure that you submit data that can be successfully decrypted.
• Only submit decrypted data that belongs to the merchant submitting the request.
• Encode the submitted data in Base64.

"

1. There was an attempt to void a refund on a processor that does not allow that.
2. A merchant on the Concord EFS platform is attempting to pass AMEX CID, when they are not signed up to validate this value with AMEX.
3. Transactions submitted from test credit card numbers (both ours and others') by merchants on the TSYS payment processing platform, will return a response of: "(180) An error occurred during processing. Please try again. Invalid processor response format," rather than "(2) Declined. This transaction has been declined."

Note that the TSYS payment processing platform was formerly known as Vital or Visanet. On TSYS/Vital/Visanet, Error 180 is an valid response indicating that a transaction was submitted and correctly received, but rejected due to using a test card number. If the processor is incorrectly configured, the response will be something more generic like a response of 30, 34, or 35.

The Security Code works by generating an image that contains random numbers and letters that cannot be read by scripts. The customer is then prompted to enter the letters and numbers exactly as they appear in the image. If the customer enters the correct Security Code, the transaction is accepted as valid.

Error 312 indicates that the customer had entered the wrong Security Code. Should this error occur, a new Security Code is generated, and the customer is prompted to try again until they are successful.

To turn off the Security Code option:

• Login into the Merchant Interface at https://account.authorize.net/.
• Click Account from the main toolbar.
• Click Settings in the main left side menu.
• Click Payment Form.
• Click Form Fields.
• Deselect the box labeled "Require the Security Code feature on the Payment Form."
• Click Submit to save the settings.

Note: When using Simple Checkout, the customer is always required to verify a Security Code. Even if the Security Code is disabled from the payment form, the customer is required to verify a Security Code on the Simple Checkout order page.

The Security Code works by generating an image that contains random numbers and letters that cannot be read by scripts. The customer is then prompted to enter the letters and numbers exactly as they appear in the image. If the customer enters the correct Security Code, the transaction is accepted as valid.

If they enter an incorrect value, the customer is prompted to try again until they are successful.

To turn off the Security Code option:

• Log into the Merchant Interface at https://account.authorize.net/.
• Click Account from the main toolbar.
• Click Settings in the main left side menu.
• Click Payment Form.
• Click Form Fields.
• Deselect the box labeled "Require the Security Code feature on the Payment Form."
• Click Submit to save the settings.

Note: When using Simple Checkout, the customer is always required to verify a Security Code. Even if the Security Code is disabled from the payment form, the customer is required to verify a Security Code on the Simple Checkout order page.

• First Name (firstName)
• Last Name (lastName)
• Address (address)
• City (city)
• State (state)
• Postal Code
• Country (country)
• Email Address (email)

NOTE: State and Postal Code are optional if the billing address is not in the U.S. or Canada. If the address is in the U.S. or Canada, the two-digit State/Province code must be provided, along with the Zip/Postal Code."