# Enrichment by business model (https://docs.chargeflow.io/docs/merchants/automation/enrich-a-dispute/by-business-model)
The evidence that wins a dispute depends on what you sell. A SaaS charge has no tracking number, so the case rests on proving the customer signed up, used the service, and knew the billing terms. A physical-goods charge turns on what was ordered and where it was delivered. Everything below is sent to the same endpoint:
```
PATCH https://api.chargeflow.io/public/2025-04-01/disputes/{disputeId}
```
Use the Chargeflow dispute ID (`dispute.id`) from the `dispute.created` webhook as the path parameter. See [Enrich a dispute](https://docs.chargeflow.io/docs/merchants/automation/enrich-a-dispute) for upsert semantics and the array merge behavior that applies to `products[]` and `fulfillments[]`.
## Find your evidence set [#find-your-evidence-set]
SaaS disputes present unique challenges. Unlike physical goods, there is no tracking number or delivery confirmation: the challenge is proving that the customer knowingly signed up, actively used the service, and authorized the recurring charge. These data points are the most effective evidence for `fraud`, `canceled_recurring_billing`, and `credit_not_processed`.
Issuers adjudicating a SaaS dispute look for signals that:
1. The customer intentionally created an account and signed up for the service.
2. The customer actively used the service after sign-up.
3. The customer was aware of the recurring billing terms.
4. If a subscription was canceled, the cancellation was processed correctly.
Without this data, your response relies solely on generic transaction metadata, which is rarely enough to win.
**Subscription information**
Send subscription data to show the charge is part of a legitimate, established billing relationship.
**Key fields** (`subscription` object):
| Field | Description | Example |
| --------------------------- | ------------------------------------------------ | ---------------------- |
| `source_id` | Your internal subscription ID | `sub_1234567890` |
| `start_date` | When the subscription started | `2024-01-15T00:00:00Z` |
| `frequency` | Billing interval: `day`, `week`, `month`, `year` | `month` |
| `frequency_count` | Number of intervals per billing cycle | `1` |
| `status` | Current status: `active`, `inactive`, `canceled` | `active` |
| `plan_name` | The plan the customer is on | `Pro Plan` |
| `pricing_model` | `fixed_price` or `usage_base` | `fixed_price` |
| `trial_start` / `trial_end` | Trial period dates if applicable | - |
| `cancellation_date` | When the cancellation was requested | - |
| `cancellation_reason` | Why the subscription was canceled | `too_expensive` |
A history of successful payments on the same subscription strongly demonstrates an ongoing, consented billing relationship: link past charges via [transaction enrichment](https://docs.chargeflow.io/docs/merchants/automation/enrich-a-dispute) with the `subscription_id` reference.
**Customer activity logs**
Activity logs are among the most powerful evidence for SaaS fraud and unauthorized transaction disputes. They prove the customer's device or session was actively used before and after the disputed charge.
| Event | Explanation | Importance |
| -------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Sign up | Sign-up timestamp, IP address, and device information | Proves the customer is familiar with the merchant and their service |
| Login | Login timestamp and IP address; send multiple events when available | Proves the customer intentionally used the service |
| Purchase | Purchase data for the service or product; send multiple events if available | Establishes that the customer knows the merchant, is familiar with the service quality, and authorized the transaction |
Send multiple login events if available. A pattern of logins over time, including events close to
the disputed charge date, is significantly more compelling than a single event.
Activity logs are attached as a file with the [Upload evidence endpoint](https://docs.chargeflow.io/docs/merchants/automation/upload-evidence) using `evidenceUploadCategory: "additional_evidence"`. Export the events with a timestamp, IP address, and user agent per event, and describe what the export shows in the `content` field.
E-commerce merchants selling physical goods face disputes most commonly around `not_received`, `not_as_described`, and `fraud`. Winning these requires proving what was ordered, that it shipped to the correct address, and that it was delivered.
**Order data**
Order data establishes what the customer purchased and at what price. It counters `not_as_described` claims and demonstrates that the customer had access to accurate product information.
**Key fields** (`order.products[]`):
| Field | API path | Description |
| ------------------- | ------------------------ | -------------------------------------------------- |
| Product name | `products[].name` | The name of the product |
| Product description | `products[].description` | Detailed description matching what was advertised |
| Product image URL | `products[].image_url` | URL to the product image shown at time of purchase |
| Price | `products[].price` | Unit price at time of purchase |
| Quantity | `products[].quantity` | Number of units ordered |
| Product type | `products[].type` | `physical_good` or `digital_good` |
Always include the product image URL when available. Issuers reviewing disputes are not familiar
with your catalog: a clear product image alongside the description makes the evidence immediately
compelling.
**Fulfillment information**
Fulfillment data is the core evidence for `not_received` disputes. A tracking number with a confirmed delivery scan is often sufficient to resolve these cases.
**Key fields** (`order.fulfillments[]`):
| Field | API path | Description |
| --------------- | ------------------------------------ | ------------------------------------------- |
| Tracking number | `fulfillments[].tracking_number` | Carrier tracking number |
| Courier | `fulfillments[].courier` | Carrier name (e.g., `FedEx`, `UPS`, `USPS`) |
| Shipped at | `fulfillments[].shipped_at` | ISO 8601 timestamp when the item shipped |
| Shipping method | `fulfillments[].shipping_line_title` | Description of the shipping service |
For high-value shipments, also upload a proof of delivery document using the [Upload evidence endpoint](https://docs.chargeflow.io/docs/merchants/automation/upload-evidence) with `evidenceUploadCategory: "tracking_information"`.
**Subscription information (if applicable)**
If you run a subscription or auto-ship model, include subscription data to demonstrate the customer consented to recurring charges: `frequency` / `frequency_count`, `status`, `start_date`, and the charge history linked via [transaction enrichment](https://docs.chargeflow.io/docs/merchants/automation/enrich-a-dispute). The SaaS block above lists the full field set; the same fields apply here.
**Full e-commerce payload**
```json title="Request body"
{
"order": {
"products": [
{
"name": "Wireless Headphones",
"id": "prod_12345",
"type": "physical_good",
"quantity": 1,
"description": "Noise-canceling wireless headphones with Bluetooth 5.2 connectivity and 30-hour battery life.",
"image_url": "https://example.com/images/products/headphones.jpg",
"price": 150
}
],
"fulfillments": [
{
"product_id": "prod_12345",
"shipped_at": "2025-01-26T18:00:00Z",
"shipping_line_title": "FedEx 2-Day Express",
"shipping_method_price": 0,
"tracking_number": "1Z999AA10123456789",
"courier": "FedEx"
}
],
"shipping_address": {
"name": "John Doe",
"line1": "123 Main Street",
"line2": "Apt 4B",
"city": "New York",
"country": "US",
"state": "NY",
"zip_code": "10001"
}
}
}
```
## Customer communication [#customer-communication]
Whatever you sell, a record of your interactions with the customer strengthens the response: conversations where you provided shipping updates, where the customer acknowledged the service, asked for a refund, or where you offered a resolution before the dispute was filed.
* **Structured messages**: use the [Customer communication endpoint](https://docs.chargeflow.io/docs/merchants/automation/enrich-a-dispute/customer-communications) to send helpdesk conversations programmatically.
* **File upload**: use the [Upload evidence endpoint](https://docs.chargeflow.io/docs/merchants/automation/upload-evidence) with `evidenceUploadCategory: "customer_communication"` to attach a screenshot.
## How to send this data [#how-to-send-this-data]
| Data | Endpoint |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Order, products, fulfillments, transaction context | [`PATCH /public/2025-04-01/disputes/{disputeId}`](https://docs.chargeflow.io/docs/merchants/automation/enrich-a-dispute) |
| Subscription record | [`POST /public/2025-04-01/disputes/{disputeId}/subscription`](https://docs.chargeflow.io/docs/api/2025-04-01/merchants/disputes/public/2025-04-01/disputes/disputeid/subscription/post) (required: `source_id`, `created_at`, `start_date`, `frequency`, `frequency_count`) |
| Activity logs | [`POST /public/2025-04-01/disputes/{disputeId}/evidence`](https://docs.chargeflow.io/docs/merchants/automation/upload-evidence) (file upload, `evidenceUploadCategory: "additional_evidence"`) |
| Communication records | [`POST /public/2025-04-01/customer-communication`](https://docs.chargeflow.io/docs/merchants/automation/enrich-a-dispute/customer-communications) |
### Confirm it landed [#confirm-it-landed]
Each call returns the updated dispute, and the record then appears on that dispute in the Chargeflow dashboard. To re-check later, read the dispute back with `GET /public/2025-04-01/disputes/{disputeId}`: that response is the authoritative view of what Chargeflow stored.
## Next steps [#next-steps]
Full endpoint reference including array merge behavior.
Structured helpdesk records.
Proof of delivery and communication screenshots.
Trigger enrichment flows automatically on dispute.created.