Reporting
This guide provides an overview on the standard reports and analytics
Standard capabilities
This section enables users to download transaction data from right within the application. 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
andOffsitePurchase
) grouped by the transaction state:succeeded, failed, gateway_processing_failed
andgateway_processing_result_unknown
- USD: Funnel view of the USD amount of transactions (
Authorization, Capture, Purchase, Verification, Credit, Void, Store, GeneralCredit, OffsiteAuthorization
andOffsitePurchase
) grouped by the transaction state:succeeded, failed, gateway_processing_failed
andgateway_processing_result_unknown
Reports
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
:
- Overview
- Success Rates
- Failures
- Transactions
- Gateways
- 3DS2
- Payment Methods
- Lifecycle Management
- Recover
- 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)
Failures
The Failures section provides insights into failure trends.
- Transaction failures: Trend of the # of
failed, gateway_processing_failed
andgateway_processing_result_unknown
transactions - Gateway error messages: Top 20 most common gateway error messages on failed transactions under the selected Organization
Transactions
The Transactions section can be used to retrieve all transactions within a given date range, as well as the API calls by environment
Gateways
The Gateways section lists out all the Gateway types added to the selected environment.
3DS2
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:
- ReplacePaymentMethod - The number and/or expiration date has been updated.
- 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.
- 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.
- 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 report will also include details on Transactions by Environment, Results by Card Type, and Eligible Cards by Type:
Recover report
The Recover 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.
Sub-Merchants
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:
FAQs
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 app.
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.
Updated about 2 months ago