This guide provides an overview on the standard reports and analytics

Standard capabilities

This capability enables users to download transaction data from right within the dashboard. One can filter on the transaction date and then download the data in a variety of formats for offline analysis. The data fields available in this view include date, transaction token, transaction type, transaction state, currency, amount, USD amount, etc. Watch this short demo video to learn more.

Overview page

The reporting Overview landing page provides a quick snapshot of overall payment performance. One can look at transaction trends, key data points and recent transactions on this page.

The following is a snapshot of the data points available on this landing page. Based on the Date and Environment you have selected in the application, a user can look at the following data:

  • Gateways:: List of all gateways that had transactions
  • Receivers: List of all receivers that had transactions
  • Avg Tkt Size: Avg $ value of all successful Purchase, Capture, PurchaseViaReference, OffsitePurchase transactions on non-test gateways
  • Transactions: Trend of all transactions by count
  • Card Brand: % Split of payment method card brand
  • Currency: % Split of currencies used in transactions
  • Payment Method: % Split of payment method type

The following funnel view provides a snapshot of the number of transactions and their US Dollar value.

  • Count: Funnel view of the # of transactions (Authorization, Capture, Purchase, Verification, Credit, Void, Store, GeneralCredit, OffsiteAuthorization and OffsitePurchase) grouped by the transaction state: succeeded, failed, gateway_processing_failed and gateway_processing_result_unknown
  • USD: Funnel view of the USD amount of transactions (Authorization, Capture, Purchase, Verification, Credit, Void, Store, GeneralCredit, OffsiteAuthorization and OffsitePurchase) grouped by the transaction state: succeeded, failed, gateway_processing_failed and gateway_processing_result_unknown


Report sections

The reporting area of the Spreedly application will provide the following sections for specific reporting areas, with each being filtered to your selected Environment:

  • Success Rates
  • Failures
  • Transactions
  • Gateways
  • 3DS2
  • Payment Methods
  • Lifecycle Management
  • Routing Rules & Retry
  • Merchant Aggregator

Users can review these same tables and visualizations combining all data across every environment in the organzation by accessing the Reports section of the Organization menu.

Success rates

The Success rates section provides insights into success rates on various dimensions:

Payment method: Success % trend by payment method
Card brand: Success % trend by card brand
Gateway: Success % trend by gateway

Success % = (# of Succeeded Purchase, Verification, Authorization, PurchaseViaReference, OffsitePurchase) / (All Purchase, Verification, Authorization, PurchaseViaReference, OffsitePurchase)

(Where transactions are neither test nor on a test gateway)


The Failures section provides insights into failure trends.

  • Transaction failures: Trend of the # of failed, gateway_processing_failed and gateway_processing_result_unknown transactions
  • Gateway error messages: Top 20 most common gateway error messages on failed transactions under the selected Organization


The Transactions section can be used to retrieve all transactions within a given date range, as well as the API calls by environment


The Gateways section lists out all the Gateway types added to the selected environment.


The 3DS2 section provides insights into Spreedly's Global 3DS2 Solution

  • SCA transactions: Trend of SCA transactions
  • Flow performed: Trend of transaction flow performed ( challenge, frictionless, etc. )
  • SCA auth response codes: Trend of SCA authentication response codes

Payment methods

The Payment methods section provides insights into the customer’s payment method details.

  • Retained payment methods: The trend of retained payment methods over time
  • Payment methods by card type and brand: View the number of payment methods by card type and card brand

Lifecycle Management

If Lifecycle Management is enabled, users will be able to see the results from the latest update runs on this page. To learn more about how to keep your Payment Methods updated, visit the Lifecycle Management page.

Lifecycle Management runs and filters

The first report seen within the Account Updater section is a summary of runs by month, including details on the the count of each of the following transaction types:

  1. ReplacePaymentMethod - The number and/or expiration date has been updated.
  2. InvalidReplacePaymentMethod - We received either a new card number or expiration date that was invalid. The payment method was not updated, and there is no charge.
  3. ContactCardHolder - Contact the cardholder for a new number and/or expiration date. This status is a flag, so no changes are made to the payment method.
  4. ClosePaymentMethod - The account is no longer open and should no longer be used. The payment method will remain available, but Spreedly’s Lifecycle Managementr will no longer attempt to update it.

Additionally, the Total column will show all transactions and the Billable Total column will show all billable transactions (excluding InvalidReplacePaymentMethod)

The Created Date filter at the top will allow you to select a specific range of dates to view Lifecycle Management runs, up to a limit of 12 months of history:

AU Transactions table & downloading

Below the updater runs summary is a table containing all transactions for your selected date range (as set by the Created Date filter noted above) including created date, payment method key, transaction token/ID/key, transaction type and card details including first six digits, last four digits, expiration month, and expiration year:

This detailed transactions table can be downloaded by selecting the “tile actions” menu at the top right and choosing “Download data”:

The download can be in a number of formats (CSV, Excel, JSON) and please note: to ensure that you retrieve all transactions for your selected time period, be sure to expand the “Advanced data options” section and select “All results” under the “Number of rows to include” section:

Note: attempting to download a greater volume of available data (such as all 12 months of available range) may result in slowness.

Additional data

The Lifecycle Management dashboard will also include details on Transactions by Environment, Results by Card Type, and Eligible Cards by Type:

Retry report

Transaction Retry: Transaction Retry Guide

The transaction retry table will show all transaction attempts that include a retry gateway.

Each payment can have many transaction attempts, there will be one record per payment attempt. 'Payment Attempts' tracks which gateway in the retry chain is - if 'Payment Attempts' is 1 the payment at the primary gateway and has not been retried yet. 'Payment Gateways' is an ordered array of gateway tokens in a payment's retry chain. 'Payment Key' is the unique id for the payment shared across attempts. If 'Payment Attempt' is 2 or 3, the transaction is at one of the retry gateways. 'Payment Transaction Keys' references the prior transaction key in a chain if there was a previous retry. 'State' tracks whether or not the attempt failed or succeeded. 'Transaction Token' identifies the current transaction attempt. 'Transaction Type' will be either Purchase or Authorize. 'Smart Routing' tracks whether the retry attempt was configured through the Routing Rules interface (Yes) or as an additional parameter in the API (No). 'Total' represents the amount on the transaction attempt converted into USD.

You can filter on the transaction Created Date, number of Payment Attempts, Transaction State, and Smarted Routed (yes/no) using the filter drop downs.


The Merchant Aggregator section will show a report with details on the selected Environment's sub merchants including key, name, total transaction count, and total USD from successful transactions:


Can I add my own custom time filters?

Customers may use the date filter to choose various filter options.

How up-to-date is this data ?

The average lag time is around 60 minutes from when a transaction occurs and the data is available for analysis. The lag applies to all reports except for data found in Transactions and Gateways in an environment.

How does transactional reporting work for merchant aggregators?
Aggregators that are segmenting their merchants via individual environments will be able to track and view payment method transactions details (number of transactions, GMV, etc.) on a per merchant (environment) basis in the dashboard.

Aggregators that have more than one merchant in an environment will need to tag their merchant gateway(s) with the sub_merchant key to get visibility into merchant transactional reporting.

In the case where multiple merchants are transacting through the same gateway (token), there is an ability to tag a transaction with the sub_merchant key directly. Note that using the sub_merchant key for each transaction will potentially provide a greater depth of data for reporting than filtering on the sub_merchant key tagged on the gateway.