Table of Contents
- What are Processor Errors?
- How do we Identify Processor Error?
- Where do we Find Response Codes?
- List of Common Processor Errors by Platform
1) What are Processor Errors?
Processor errors are errors reported to the gateway from the Credit Card or ACH platform boarded to the merchant account.
These errors indicate there is an issue with either:
- The CONFIGURATION/SETUP of the platform within the gateway.
- Check VAR info against what was entered in the gateway for possible keying errors.
- Check the List of Commons Errors below.
- Contact processor for additional troubleshooting assistance.
- The TRANSACTION DATA submitted to the gateway.
- Check the List of Commons Errors below.
- Contact processor for additional troubleshooting assistance.
- Important Note: These errors are NOT generated by the gateway. We are simply the messenger between the merchant and the processor.
2) How do we Identify Processor Error?
400 - 461 Response Codes: Processor errors can be identified by their response codes, which are in the 400 range. Below is a list of possible processor response codes and their general description.
CODE | GENERAL DESCRIPTION |
400 | Transaction error returned by processor. |
410 | Invalid merchant configuration. |
411 | Merchant account is inactive. |
420 | Communication error. |
421 | Communication error with issuer. |
430 | Duplicate transaction at processor. |
440 | Processor format error. |
441 | Invalid transaction information. |
460 | Processor feature not available. |
461 | Unsupported card type. |
- Important Note: The general description is likely NOT what you will find on failed transactions. You will find the actual response from the processor. We map their responses to our codes listed above to achieve standardization.
3) Where do we Find Response Codes?
- Transaction Response: The response is usually shown right after the transaction is submitted however some methods such as API will show the code and some methods such as Virtual Terminal transactions will not.
- Query API: The response codes can be pulled by creating a simple Query API call, which you can process directly from your browser. Please see below for instructions.
How to Pull a Transaction Response using Query API
1) Add an API key and the Transaction ID after the equal sign (=) in the string below.
https://secure.networkmerchants.com/api/query.php?security_key=transaction_id=
- Where can I find the API key? The API key can be created from the merchant control panel under Options>Settings>Security Keys.
2) Then open a browser of your choice (Google Chrome, FireFox, IE, Safari etc)
3) Copy and paste the string into the web address bar and hit the Enter button
4) You should now see the full response of the transaction. Select Ctrl + U (or right-click on the browser and select the ‘View page source’) to see the results in formatted in XML.
5) Scroll down to the bottom to see the response code and text. It will look something like this:
<response_text>Bad Bin or Host Disconnect</response_text> <response_code>410</response_code>
- Important Note: Make sure to omit any extra spaces from the string otherwise the query attempt will fail.
4) List of Common Processor Errors by Platform
INV BATCH SEQ
- Batch Sequence: If anything upsets the batch sequence at Omaha, this error will be received.
- Force Close of Batch: Closing out a batch manually outside the gateway. Sometimes called "force closing" a batch.
- Re-routing Refunds: This will be seen when an Omaha MID is closed and refunds are not re-routed and someone tries to run a refund.
- MID number change (historical): We used to see this when the MID number was changed inside an already existing setup, rather than a new MID being added and refunds rerouted to the new MID. This is now blocked on Omaha to prevent this problem.
INVALID AMOUNT
- Max ticket amount be set at the processor level. The affiliate will need to contact either the processor or the customers bank to get more information.
- Transactions over are not allowed 99,999.99
INVALID MRCH #
- Affiliate must call Omaha to verify the info in the gateway compared to set up at Omaha. -Could mean not set up for AMEX if an AMEX being attempted.
INVALID TRAN TYPE (INV TRAN TYPE)
- The account is new. This response will also show in the 24 hour set up period.
- A test card (ex. 411111...) was used on the account.
- ETC (Electronic Ticket Capture) needs to be set as ETC Type 7 (terminal based settlement) as opposed to ETC Type 3 (host based settlement). (This isn't a gateway setting, they will need to Contact First Data Omaha to change).
- If this is only happening on specific cards, they will need to contact FDMSO to determine why this message was returned.
INVALID CARD #
- Merchant received a INVALID CARD # when trying to use a prepaid chase card on Omaha.
- Unsure if they take this type of card.
- The card# passed our LUHN10 Validation, however the Issuer believes this to be an invalid credit card number.
- Have the customer verify their information or contact their card issuer for more information.
Bad Bin or Host disconnect
- Check VAR: Check VAR data against the processor configuration in the gateway to confirm there are no entry errors.
- Check settlement type: Check with TSYS to make sure the setup is terminal based settlement. Can get this message when the account is set up as host based settlement.
- SSL Flag: The SSL flag should be set to 'Y'.
- Merchant Category: A bad 'Merchant Category' can return this message.
- Check BIN: It could literally be a bad BIN, or a mistypes BIN (Bank ID #) on the VAR sheet.
Re-enter transaction
-
Check Zip Code/Address Info under Merchant Information Section (or within the processor config): Check the basic data entered for the merchant; in this case the merchants zip code was only 4 digits and when the trans was entered it came back as a failed trans; re-enter transaction.
- Zip entered as "OH" caused same error
- Had a merchant getting this error, their Zip was ok. However, the State was spelled out in the configuration [check "More fields..." in the pencil]. Two letter state "AL, IL, PA etc" is needed. Either delete the field or replace [for example "Tennessee" with "TN"], or delete the field from the processor pencil and it will be pulled from the profile... and their transactions started working.
Transaction not permitted by issuer
- Occurs on 'Validate' transactions. Root cause unknown. Have heard on other processors that the acquiring bank can be an issue, but not sure if that is the case here.
- Apparently can also happen on transactions where TSYS is not able to run the card. Seems this may be the case when the card cannot be run in that specific currency.
Activity Limit Exceeded
- This is a decline message that means the credit card being used has reached it's limit. Frequently seen if a test card is used on a live account.
Daily Threshold Exceeded
-
-
-
- There can be a daily limit set at TSYS for a merchant, will see this response when they've gone above it. (May be setup error rather than real limit). Need to follow up with processor.
-
-
Paya/Nuvei:
This processor requires a valid ['fieldname'] for credit transactions. Please enter the required information and resubmit.
- If a credit transaction is missing any of the required fields, the following error message will be returned:
Mandatory Fields for Paya ACH Credit Transactions:
Address
City
State
Zip