Exception Codes in the -1600 Series

Exception codes beginning with -16xx typically occur either when a card authorization fails or during the batch settlement process in TouchNet Payment Gateway.

In the first scenario, the customer is attempting to pay with a credit or debit card when the processor declines the authorization for a specific reason. The reasons vary by processor, but some examples may include transactions that exceed the card's available balance, transactions where the card is expired, transactions where the card has been reported lost or stolen, or transactions where the security code or PIN is incorrect. Other examples may include more contextual problems, such as an invalid merchant ID, an invalid terminal ID associated with the point-of-sale device where the card was swiped, or a host timeout. Still other instances may simply require the customer to call the card-issuing bank for verification before the authorization can be processed successfully.

In the second scenario, the card may have successfully authorized but the credit card batch it is associated with fails in Payment Gateway due to a particular problem with the processor. Again, the reasons vary by processor but they may include generic system errors, host or processor timeouts, or invalid service codes.

The following credit card processors may produce an exception code in the -1600 series:


General information about resolving errors in the -1600 series

Because each exception code in the -1600 series maps to a different response from one of the processors listed above, no universal solution applies to each exception code. For instance, a -1603 may mean "Invalid merchant ID" for Global Payment Systems East, while it means "card issuer does not want that card used" for Paymentech and "Cardholder not found" for Elavon.

As a result, each exception code in the -1600 series that is documented in the Client Community will display the generic response from the processor, along with some suggested solutions for successfully authorizing the transaction or resubmitting the batch in Payment Gateway. While these solutions vary, they essentially boil down to three basic types:


Problems that can only be resolved by the customer

Sometimes the error must be resolved by the customer. For instance, the exception code may indicate that the customer is entering an invalid PIN or an incorrect expiration date or it may indicate that the processor requires the customer to call their card-issuing bank before the authorization can be approved.

Unless you receive an exception code that specifically asks you to pick up the card (because it has been reported lost or stolen) or that requires some type of verbal authorization from the cardholder, TouchNet recommends you prompt the customer to try and enter their information a second time rather than directing them to the information they entered incorrectly. A simple statement like the following is suggested: "Please verify your card information and try again. If you feel that you have received this message in error, please contact your issuing bank using the information on the back of the card."


Problems that can only be resolved by your institution

On occasion, the exception that occurs with the processor may be due to a configuration or setup error with your institution. Some examples of these may include an invalid merchant number within your Payment Gateway, a timeout error, or a merchant that is not correctly set up to process debit or credit transactions.

If the exception code displays as a result of a configuration or setup error on your campus, a set of possible solutions will be provided to help you troubleshoot the issue. If problems persist, you are advised to contact TouchNet Customer Care.


Problems that can only be resolved by the processor

Still at other times the problem causing the exception code to display may reside with the processor itself and may require you to retry the transaction or resubmit the batch at a later time. Some examples include network failures, timeout errors, or communications errors that prevent an authorization from being validated.

In these instances, your institution is typically encouraged to contact the credit card processor to ascertain whether they authorized the card transaction or whether they received the batch in question. Typically, the processor should be able to help you determine what the appropriate course of action should be (retry the transaction or batch again now, retry later, etc.), although each exception code will include some additional instructions on how to re-submit a failed batch or when to contact TouchNet Customer Care for assistance.