> ## Documentation Index
> Fetch the complete documentation index at: https://docs.knotapi.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Dispute Deflection
> Reduce first-party fraud by showing users exactly what they purchased before they file a dispute.
> This is a product use case page. When implementing, follow the linked quickstarts for canonical API setup steps rather than inferring them from this page.
## Problem
A significant share of transaction disputes filed by cardholders are not true fraud. They are first-party disputes, sometimes called "friendly fraud," where a user disputes a charge they actually made. This happens for a few reasons: the user does not recognize a charge amount, they forgot what they ordered, or they find it easier to dispute than to track down a receipt. Traditional transaction feeds show a merchant name and a dollar amount, but that is often not enough for a user to confidently confirm a purchase was theirs.
Every dispute costs the card issuer time and money, whether or not it turns out to be legitimate. Investigations, provisional credits, chargeback fees, and support interactions add up. If you could show users what they actually bought before they escalate, many of those disputes would never be filed.
## Solution
Use SKU-level transaction data from Knot's [Sync Transactions](/api-reference/products/transaction-link/sync) endpoint to display the exact items purchased in a transaction, along with fulfillment details like order status and delivery confirmation. Surface this information on the transaction detail screen, and again at the point where a user initiates a dispute. When a user sees the specific products they ordered and that the order was delivered to their address, they can immediately recognize the charge as legitimate.
This creates a natural deflection point: users confirm the purchase is theirs and abandon the dispute before it enters your investigation pipeline, saving your team from unnecessary chargeback work.
## Flow
```mermaid placement="top-right" actions={false} theme={"system"}
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#f5f5f5', 'primaryTextColor': '#000', 'primaryBorderColor': '#000', 'lineColor': '#000', 'secondaryColor': '#f5f5f5', 'tertiaryColor': '#f5f5f5', 'edgeLabelBackground': '#fff', 'fontSize': '16px'}}}%%
flowchart LR
A[User switches their card at a merchant through Knot or links their merchant account] --> B[Sync SKU-level transaction data from Knot]
B --> C[User initiates a dispute on a transaction]
C --> D[Display itemized products and delivery details]
D --> E{User recognizes the purchase?}
E -->|Yes| F[User cancels the dispute]
E -->|No| G[Proceed with dispute flow]
```
## Implementation
When a user switches their card at a merchant or links their merchant account, Knot begins collecting transaction data for that account. Listen for the [`NEW_TRANSACTIONS_AVAILABLE`](/transaction-link/webhook-events/new-transactions-available) webhook event, then call [Sync Transactions](/api-reference/products/transaction-link/sync) to pull the user's transactions. Store the SKU-level data so it can be retrieved when the user views or disputes a transaction.
As transactions are updated (e.g., an order ships or is delivered), listen for the [`UPDATED_TRANSACTIONS_AVAILABLE`](/transaction-link/webhook-events/updated-transactions-available) webhook and re-sync the affected transactions via [Get Transaction By ID](/api-reference/products/transaction-link/get-by-id) to keep fulfillment status updated.
Persist the SKU-level transaction data so it can be retrieved when a user views a transaction in your app. Match each SKU-level transaction from Knot to the corresponding card transaction in your system using [this guide](https://docs.knotapi.com/transaction-link/quickstart#transaction-matching) to determine exact fields to match on.
When a user taps on a transaction in your app and the user is navigated to the transaction detail screen, display the fully-enriched set of transaction information, including the products, order status, and delivery information. In this way, they are more likely to recognize their purchase.
Only display transactions with `order_status` of `COMPLETED`, `DELIVERED`, `PICKED_UP`, `SHIPPED`, `BILLED`, or `ORDERED`. Filter out `CANCELLED`, `REFUNDED`, and `FAILED`.
**Additional fields to display:**
| Field | Purpose |
| --------------------------- | -------------------------------------------------------------------------------------------- |
| `products[].name` | Product name for display. |
| `products[].description` | Product description for display. |
| `products[].image_url` | Product image URL to display the image of each product. |
| `products[].url` | Product URL to link out to the product. |
| `products[].price.total` | Price paid for each product for display. |
| `products[].external_id` | Unique product identifier. |
| `order_status` | Current status of the order (e.g. `DELIVERED`, `SHIPPED`). |
| `shipping.location.address` | Delivery address including `line1`, `line2`, `city`, `region`, `postal_code`, and `country`. |
**If Knot SKU-level txn information is NOT available:**
There are a few scenarios where your system may not have enriched, SKU-level transaction data from Knot for a corresponding card transaction in your system. Below are each scenario outlined with their solution if applicable:
| Scenario | Solution |
| --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The corresponding merchant account was never linked to your app or is currently disconnected. | If your system is aware of the merchant for the transaction, display a button on the transaction detail screen requesting the user link (or relink) the appropriate merchant account. If your system is not aware of the merchant, display an identical button that instead navigates to a list of merchants for the user to choose to link. |
| The transaction is recent (e.g. occurred within the last 24 hours). | Call Knot's `Refresh Transactions` endpoint to refresh the synced SKU-level transactions or simply do not display the enriched information. |
This makes the enriched experience feel like a natural upgrade rather than an inconsistent feature.
If a user chooses to initiate a dispute on a transaction where SKU-level transaction data is available, insert a confirmation step before the dispute flow that surfaces the enriched, SKU-level transaction data below:
| Field | Purpose |
| :-------------------------- | :------------------------------------------------------------------------------------------- |
| `products[].name` | Product name for display. |
| `products[].description` | Product description for display. |
| `products[].image_url` | Product image URL to display the image of each product. |
| `products[].url` | Product URL to link out to the product. |
| `products[].price.total` | Price paid for each product for display. |
| `products[].external_id` | Unique product identifier. |
| `order_status` | Current status of the order (e.g. `DELIVERED`, `SHIPPED`). |
| `shipping.location.address` | Delivery address including `line1`, `line2`, `city`, `region`, `postal_code`, and `country`. |
If the user confirms the purchase is theirs, dismiss the dispute flow and return them to the transaction detail screen.
If the user does not recognize the purchase, proceed with your standard dispute flow. The enriched data still has value here: your investigations team can reference the itemized breakdown when reviewing the case, reducing the time spent manually researching the transaction.
## Expansion Path
* **Dispute analytics** - Track how often users abandon disputes after seeing the enriched breakdown versus how often they proceed. This gives you a measurable deflection rate to quantify the impact on chargeback volume and operational costs.
* **Dispute operations tooling** - Expose the same enriched transaction data to your dispute operations team. When a user calls in about an unrecognized charge, the agent can read back the specific items and delivery details, resolving the inquiry without escalating to a formal dispute.