For identifying the source of credit card processing failures.
When a credit card is processed within the software, the buyer and transaction details are encrypted and sent to the gateway. The gateway validates that the necessary info is provided and that the card is valid. It then sends the transaction to the Merchant Processor for approval of the requested charge. The status of the transaction (successful, failed) is then reported back to the gateway, then the software and will appear on the screen as a confirmation message.
The failure message often provides clues about where and why the transaction failed and should be the starting point when troubleshooting: Is the failure specific to an individual card or transaction, or does it indicate an issue with the Gateway or Merchant Processor account?
1. Review the failure message:
If the failure message is no longer visible on your screen:
Go to Orders:
Search to see if the failure was logged on an existing order. If so, click on the info icon next to the failed payment to review the failure message.
If the transaction does not appear on the Orders page, it's because the credit card failed during the initial online transaction (ticket sale or donation page) so the order was never completed. Options for investigating further:
- Ask the buyer if they can still see their transaction (temporary orders expire after 30 minutes) and/or to try again, this time making a note of the error message (or sending you a screen shot).
- Try to reproduce the error on your end. If other credit cards transactions are working on your site, the issue is likely specific to their card and/or address info. Verify that the card is valid (accepted card type, not expired etc.)
- Login to your gateway account to review the failure message there (knowing the date and approximate time will help).
2. Interpreting the Failure Message
Each gateway provides their own failure messages. Some are very specific, others are very general but you may be able to find more detailed explanations of response codes online using these links:
Some gateways return a single response code to the software, even though there are multiple problems. . .and some may return a random code if the error does not have its own dedicated code so keep an open mind when investigating!
WePay: To prevent scammers from using online applications to test the validity of stolen cards, the WePay gateway does not return a specific error message to the software. Most card specific failures will return this error message: "Transaction Declined due to mismatched CVV, AVS, or Bank Decline."
WePay may also reject test transactions using the same email address as was used to setup the WePay account - WePay's fraud filters are likely to reject these transactions as potential money laundering or unauthorized "withdrawals".
Authorize.net: May display a generic "decline" message for issues related to your merchant processor OR the individual card being used.
If the failure message returned to the software is not specific enough to allow you to address the problem, you will need to either login to your gateway account to view the specific error message(s) provided for the transaction and/or contact your gateway account rep for assistance.
To view all Credit Card Transactions, go to: Admin > View Reports > View Summary Reports > Sales/Revenue > Common Follow-up Reports (bottom of screen) > Credit Card Report
3. Common types of failures:
Although each gateway provides their own unique set of response/reject messages and codes, they may share key words that provide clues to the source of the problem:
A. Failure Messages referring to Invalid Login, Password, Authentication, or Permissions:
Generally indicate that the either API login/password entered into the software is incorrect OR that your gateway account is not authorized to vault credit cards.
Some gateways (Authorize.net, NMI and PayTrace) require specific permissions or features to be enabled in order to vault cards. If the vault feature is not active on your account, transactions can be processed, but attempts to vault will fail.
1. For most gateways, the login/password used to access your account online is different than the API login/password used to connect the software to your gateway. Check the sample formats on the instructions below to make sure you have entered the API login/password. If your API login/password appear to be properly formatted, contact your gateway account rep for assistance.
2. Enable Vaulting on your gateway:
- Login to your Authorize.net account to enable CIM (Customer Information Manager)
- Contact your NMI (or Diamond Mind) or PayTrace account rep to set up your gateway to allow vaulting.
3. Authorize.net gateways only: Verify that your auth.net gateway is not being used on another web application. If it is, the API login may have been inadvertently updated on one application, but not the other and/or one use may require settings which are incompatible with the other. It can be very difficult to use the same gateway account on multiple web application w/o interference - we recommend either disabling one during your event or setting up another gateway for your event
B. Failure Messages referring to "Invalid Merchant Account or Merchant ID"
Generally indicate that the connection between the gateway and merchant processor account is broken.
- Merchant Account is inactive (possibly to avoid monthly fees or triggered by inactivity)
- Merchant Processor has changed (perhaps your bank switched providers, your Merchant Processor merged with or was purchased by another company, or your account was changed)
Contact whomever set up your Merchant Processor to verify account status (often your bank rep, or it may have been set up through your gateway account rep).
C. Failure Messages referring to "CVV/CVV2"
CVV refers to the 3 or 4 digit Card Verification Value printed on the back of card. It is a security tool to ensure that online transactions are being made with the actual credit card in hand (rather than a stolen card number or the data poached from the magnetic strip).
A CVV or CVV2 mismatch message indicates that a CVV code is required for the transaction and the one provided (or missing) does not match the CVV associated with the card. Since the CVV is simply printed on the card, it is fairly common for the CVV to be smudged or worn off. . .
Note: Card readers/swipers require the physical card to be present in order to operate, so the CVV code is redundant as a security tool.
WePay is the only gateway which requires CVV on all transactions. The other gateways generally allow you the choice of requiring or disabling the CVV security measure. Many will have the default setting to "require", but this can be changed in your account.
- Retry the transaction with the correct CVV. If the CVV is smudged or illegible, try inserting the letter "i" in the CVV field - some gateways accept this as a code for an illegible code.
- If transaction still fails, contact your gateway account rep for assistance.
- For all gateways other than WePay, we recommend disabling the CVV requirement on your gateway. Buyers will be asked to provide the CVV for all online transactions on your site either way, but disabling the requirement will not block transactions with smudged or worn CVV codes.
D. Failure Messages referring to AVS, Name, Address, City, State, Zip mismatch
Address Verification System (AVS) are optional security settings on your gateway to require that transactions provide contact information that matches the account billing information.
WePay is the only gateway which requires Zip code as an AVS setting on all transactions. The other gateways generally allow you the choice of requiring or disabling each level of the AVS security measure. Many will have the default setting to "require", but this can be changed in your account.
- Retry the transaction with the correct billing information.
- For all gateways other than WePay, we recommend disabling all AVS settings on your gateway. While it seems a simple thing, you'll be surprised at how often customers insist the billing info is correct, but the transaction is still blocked. You won't have the ability to confirm or deny that - resulting in frustration all around. Better to disable AVS - at least for your gala event.
E. Failure Messages referring to "Decline"
Most gateways (except WePay and Authorize.net) reserve the "Decline" response for cards which are approaching or have exceeded their limit. If the transaction amount is very large, a reduced amount may be successful.
- Ask for another card or payment method. It's also a good idea to provide your team with a standard response to declined cards to minimize the awkward moment eg "It doesn't seem to like this card, do you have another card you'd like to use?"
- For Auth.net: if other transactions are being processed as expected, the decline is almost certainly card related. If all transactions are failing, it is likely an issue with your merchant processor. Contact Auth.net for assistance.
F. Failure Messages referring to AMEX
If AMEX is mentioned, it almost certainly means that your gateway and/or Merchant Processing account is not set up to accept AMEX. If an AMEX card fails with a generic failure message, you should verify that other AMEX transactions have been successfully processed:
Go to Admin > View Reports > View Summary Reports > Sales/Revenue > Follow-up Reports (bottom of page) > Credit Card Report (see below). This report shows the details of every credit card transaction processed on the site. If all AMEX (cc numbers starting with 3) have failed, your account is not set up to accept AMEX.
If there are successful transactions to AMEX cards, the problem is specific to the card (troubleshoot further using steps outlined previosly).
- Contact your Merchant account rep to add the ability to accept AMEX transactions OR
- Have a Chair user change the "credit cards accepted" setting at Admin > Site Settings > Payment/Credit Card > Setup Gateway.
G. Failure Messages that contain: "Do not attempt the transaction again"
These messages are received when the transaction timed out somewhere between the gateway and the merchant processing account.
Transaction requests are sent from the software to the gateway - which validates them for basic compliance (req. info is provided etc) then forwards them to the merchant account for approval. The merchant account then approves or denies and sends the appropriate response code back to the gateway, which forwards it to the software.
If the transaction times out before completing, the gateway path used by the software doesn't know if it was approved or denied, so returns that message.
You'll need to login to your gateway directly to see if the transaction was successful or not. If it was, let us know and we can override the message. If it wasn't, you'll need to process the transaction again.