Reports - Failed Transactions
IN THIS ARTICLE
Failed Transactions Overview
Failure Source
Gateway Failures
Saffire Failures
3DS Failures
Permitting/Preventing Additional Attempts
Error Types (F, G, S)
RELATED ARTICLES
Spark Location: Commerce > Reports > Failed Transactions
This will be your go-to report when you have a customer reach out for help because they're struggling to complete a sale on your website. This report can also be used to add cardholders to the allowlist or denylist for online transactions.
In addition to the customer data, we will also display the Source and the Failure Reason for the transaction.
Online Transactions Only
The Failed Transactions Report collects information from failed online transactions only, and does not collect data from failed in-person transactions either through the SaffireTix App or Web Box Office.
Failed Transactions Overview

- Date picker
- Keyword search
- Transaction timestamp
- Customer information
- Failure source
- Failure reason
- Export
Why Failed Transactions Don't Always Indicate a Problem
While a failed transaction sounds like a problem, it is often an indicator that the Saffire system is doing it's job correctly. There are several reasons for failed transactions that don't indicate any kind of internal error or system outage:
1. Fraud Protection Tools: Saffire’s fraud protection settings, like Denylist rules, velocity limits, or 3D Secure (3DS) authentication failures, might block transactions.
2. Customer Errors: Mistakes such as entering incorrect card details, CVV mismatches, or address mismatches can lead to failures.
3. Insufficient Funds: If the cardholder doesn’t have enough funds, the transaction will fail.
4. Gateway-Specific Issues: Errors like "Internal Server Error" or "Declined" could be related to the gateway, but they’re often caused by external factors, such as the customer’s bank or network interruptions.
5. Technical Issues: Server-level or network problems on can result in failures, including a spotty network connection on the cardholders part.
Failure Source
The source field tells you whether the transaction failed due to an issue or protection on your payment gateway, 3DS, or Saffire's internal velocity filter.
The sources listed will include:
- Saffire - indicates the transaction was prevented by Saffire's internal velocity filter. Further info
- Payment Gateway (Magensa, Card Connect, Clover, Payflow Pro, etc) - indicates the transaction reached the payment processor and then failed. Depending on which gateway you utilize, the gateway's name will be displayed. Further info
- 3DS* - Indicates the transaction was prevented by 3D Secure, an add-on Fraud Protection service. Further info
*Available through select payment gateways. For more information about 3DS, please reach out to us via support@saffire.com and we will happily explain how this service works and discuss pricing.

Gateway Failures (Type G)
If the failure source is your payment gateway, it will show the name of your individual gateway provider (Magensa, Clover, Card Connect, Payflow Pro, etc) as the source. A failure that originates with your gateway can have many different error reasons, from simple insufficient funds to server outages at the payment processor. If you have questions about why you are experiencing a particular error, please visit our Payment Processor Error Codes article or contact Saffire support by clicking the orange button below. We will do our best to help, but keep in mind that the error messages seen here are provided by the gateway, so for exact details about the failure reason you may need to contact your payment gateway representative.
Saffire Failures (Type F)
When the source of the failure is indicated as Saffire, we will explain if these are due to any Denylist Rule or Velocity Sales or Transaction Limits that have been set. Saffire velocity filter rules are covered in more detail in our Fraud Protection article.
Here are some of the common error messages associated with the Saffire velocity filter:
Per Email/IP Address/Credit Card Gateway Declines Limit Hit
Payment gateway and 3DS declines such as CVV mismatch, incorrect address entered, etc., can count toward a customer's Saffire Velocity Filter decline limits. Once a particular limit is reached, additional attempts from the same customer will be automatically declined, with the specific limit noted as the failure reason.
Decline limits apply across multiple rules. Even if a customer switches to a different email address, the system will continue to evaluate attempted transactions by email address, IP address, and credit card. If the IP address has already reached its decline limit, further attempts from that IP will continue to be declined even if a new email address or credit card is used.
IP address does not match the one used during checkout
Some errors may also occur when the IP address changes during checkout. If the IP address recorded at the start of the session does not match the IP used at the time of payment, the transaction may be blocked for security reasons. This can happen if a customer’s network changes mid-checkout. Advising your customer to refresh their browser and attempt the transaction again may clear up this error.
IP addresses can also be impacted by private browsing modes, particularly when using iCloud private relay on iPhone or iPad devices. Advising your client to exit private browsing mode may allow them to complete their transaction.
Allowlist/Denylist Rule Tripped
This message indicates that an explicit rule set up in your Fraud page has caused this transaction to be denied by Saffire. The message will show you the name of the rule, visit Commerce > Fraud Protection to view/edit rules. More allowlist/denylist info
3DS Failures (Type F)
When the source of the failure is indicated as 3DS, we will include the error message provided to our system by 3D Secure. You can find more info on 3DS in our Fraud Protection article.
Some of the reasons include:
Card Authentication Failed
Indicates the cardholder could not verify their identity through 3DS
Attempted
The card network provided proof of an authentication attempt because the issuer is not participating in 3DS or was unavailable
Internal error, could not get token from PAN. Please try request again
This can indicate a brief outage with 3D Secure. We recommend the client attempt again. If you are seeing a significant amount of these errors in a small time period, please contact Saffire Support.
Transaction Data not Valid
This may indicate that the issuing bank or payment gateway rejected the purchase because the data transmitted (e.g., billing address, card details, or metadata) didn't match their records or the required 3DS formatting.
Authentication attempted but not performed by the cardholder
The 3D Secure challenge was triggered, but the cardholder either abandoned the prompt, closed the window, timed out, or did not complete the required second-factor approval.
3DS analysis is missing
May indicate the cardholder’s bank did not run the 3D Secure authentication on that particular card, so our system never receives any 3DS data to display. This often happens with cards that are not enrolled or not supported for 3D Secure by the issuing bank. In those cases, the transaction may still be processed or declined by the bank or gateway as a normal card payment, but there just isn’t a 3DS result for us to show in the 3DS Analysis report. The next step is usually for the customer to either try a different card or check with their bank to see whether their card is enabled for 3D Secure and why the transaction did not go through as expected.
If the source is coming from 3DS, you can also find more information under Commerce > Reports > 3DS Analysis.

Permitting or Preventing Additional Attempts
To allow your customer to try their card again or attempt a different payment method, you can allowlist the customer’s email address or IP address. Allowlisting is available from the Failed Transactions Report by hovering over the timestamp of a failed attempt and selecting Add to Allowlist. Each attempted email address must be allowlisted individually, and you may also choose to allowlist the most recent IP address used.
For comprehensive steps to allowlisting and information on preventing further attempts, visit the Fraud Protection page.
Allowlisting bypasses fraud-limit blocks but does not override declines issued directly by the payment processor, such as those caused by CVV mismatches. If the original decline reason has not been resolved, the cardholder may continue to be declined.
For more information on Saffire fraud prevention settings, visit the Fraud Protection page.
Error "Types"
When an online customer receives an error message at checkout, there will be an indicator at the bottom of the error message for "Type."
Type F - Type F errors indicate the transaction was stopped because the system has detected patterns that look like fraud, so the fraud protection tools have been deployed. This either means the Saffire Fraud Protection tools or 3DS tool rules have stopped the transaction. You can check the Failed Transaction Report to see which fraud protection tool blocked the transaction.
Type G - Type G errors indicate the transaction was stopped at the Payment Gateway. This is often due to insufficient funds, CVV mismatch or address mismatch. It often relates to errors the user made typing in their payment details.
Type S - Type S errors indicate server level issues. Saffire should be contacted immediately at support@saffire.com for Type S errors.
For ALL error types, we provide as much information as we can in the Failed Transaction Report for why the transaction was blocked to help you support customers experiencing issues at checkout. You can typically get more information about Type G - Gateway errors by logging into your gateway account's online admin tools, or by contacting your gateway representative.
For more information on common error codes, visit our Knowledgebase article Payment Processor Error Codes.