The Disputes Research & Downloads dashboard provides full visibility into every chargeback and dispute event, from the initial dispute to its final resolution. With dedicated lifecycle tracking and 120+ fields, this dashboard is your go-to resource for chargeback investigation, operational reporting, and recovery validation.
It's built for fraud, compliance, finance, and risk teams who need to answer detailed questions like:
-
"Was this dispute reversed?"
-
"What stage is it in?"
-
"How many chargebacks were received for this issuer and card type?"
On-Screen Notice
The dashboard displays the following banner at the top of the page:
Use Parent tab to view the initial chargeback cases. Use Lifecycle tab to see the full chargeback flow to its final outcome.
Check your date range first. The Dispute Date filter defaults to the last 3 days, not a longer window. Widen it before drawing any conclusion about dispute volume or before exporting.
What It Does
-
Displays transaction-level dispute data
-
Tracks multiple stages of the dispute lifecycle
-
Offers two data views:
-
Parent – the initial chargeback cases, one row per dispute
-
Lifecycle – the full chargeback flow through to its final outcome, one row per stage
-
-
Enables advanced filtering by card, MOP, issuer, MID, and more
-
Allows CSV download of filtered views
This dashboard returns records, not aggregates. For dispute rates, win rates, recovery totals and fee impact, use the Disputes Dashboard instead.
Key Feature: Lifecycle Tabs
The dashboard offers two views for navigating dispute events. Which one you pick determines both what a row means and which filters are available to you.
|
Tab |
Description |
|---|---|
|
Parent |
One row per dispute (deduplicated view). Best for overall summaries, counts, and high-level investigation. |
|
Lifecycle |
Multiple rows per dispute, one for each stage (e.g., Initial Chargeback, Representment, Pre-Arb). Use for tracking full case timelines and resolution. |
The Lifecycle tab is especially powerful for chargeback teams tracking outcomes over time or managing staged resolution.
Because Parent deduplicates to one row per dispute and Lifecycle does not, counting rows on the Lifecycle tab will overstate your dispute volume. Count on Parent, investigate on Lifecycle.
Filtering Panel
The filter panel is not identical across the two tabs. Most filters are shared, but each tab carries a few of its own, so a filter you used on one tab may not be present when you switch.
Available on both tabs
|
Filter Name |
Function |
|---|---|
|
Acquirer (PSP) |
Filter to a specific payment service provider or processor |
|
ARN |
Search by Acquirer Reference Number (exact match). The most reliable way to pin down one specific transaction |
|
BIN (First 6) |
Enter first six digits of card number (BIN) to analyze issuer trends |
|
Card Issuer Group |
Filter by card issuers |
|
Card Number |
Filter by card number pattern (masked, ends with) |
|
Case ID |
Search by dispute case identifier (exact match). Use this to follow one case from Parent through to its Lifecycle stages |
|
Dispute Amount |
Filter by minimum and maximum dispute value |
|
Dispute Date |
Defaults to the last 3 days. Widen it before any volume analysis or export |
|
Dispute Type |
Select by type of dispute |
|
Merchant Order Number |
Search using exact or partial merchant order reference |
|
MID |
Filter by specific Merchant ID |
|
MID Name (Division) |
Select by merchant division name |
|
MID Rollup 2 (Harmonize Group) |
View grouped MIDs under a harmonized rollup |
|
MOP Name |
Refine by method of payment |
|
Response Due Date |
Set a date range for when responses are due. Useful for working a queue by deadline rather than by age |
Parent tab only
|
Filter Name |
Function |
|---|---|
|
Merchant Account |
Look up transactions by merchant account |
|
Network Category |
Group by network-level dispute category |
|
Network Reason Code |
Filter disputes by network-provided reason code |
Lifecycle tab only
These four are what make the Lifecycle tab worth switching to. They filter on where a case has got to and what happened at each stage, which the Parent view cannot express.
|
Filter Name |
Function |
|---|---|
|
Current Position |
Where the case currently stands in the dispute flow. This is the filter to use when you want cases at a particular outcome or stage |
|
Merchant Action |
What action was taken at a given stage, such as whether the case was represented or accepted |
|
Method of Payment |
Payment method filter specific to this tab, alongside MOP Name |
|
Reason Code |
Stage-level reason code, distinct from the Parent tab's Network Reason Code |
Use combinations of filters to isolate problem issuers, MOPs, or stages.
Downloading the Data
-
Choose your preferred view: Parent or Lifecycle
-
Apply filters to isolate your dispute cases, starting with Dispute Date since it defaults to only three days
-
Click Download CSV at the top right of the filter panel
Downloads are limited to 1 million records. If you are near that ceiling, narrow by date range or MID and export in batches rather than assuming you received everything. Clear Filters, next to the download button, resets the panel without reloading the page.
CSV is the only export format offered here.
Example Use Cases
|
Goal |
How To Filter |
|---|---|
|
Find all disputes from Issuer X in the last 90 days |
On Parent, set Card Issuer Group or BIN (First 6), then widen Dispute Date to 90 days |
|
Export disputes that reached a particular outcome |
Go to the Lifecycle tab and filter on Current Position, adding Merchant Action when you need to know what was done at each stage |
|
Track dispute stages for a high-value transaction |
Find the case on Parent, then use its Case ID or ARN on the Lifecycle tab to see every stage of that one case |
Best Practices
-
Widen Dispute Date before anything else, since three days will not show you a trend
-
Start with Parent for summaries and counts, then switch to Lifecycle for time-based or stage-specific analysis
-
Apply filters iteratively to narrow focus before downloading
-
Carry a Case ID or ARN across tabs rather than rebuilding filters, since the two tabs do not offer the same filter set