SaaS enrichment
Evidence for SaaS and recurring-billing disputes: subscription fields, customer activity logs (sign-up, login, purchase events), and communication records.
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. The data points in this guide are the most effective evidence for SaaS dispute reasons, including fraud, canceled_recurring_billing, and credit_not_processed.
Why SaaS disputes need subscription and activity data
Issuers adjudicating SaaS disputes look for signals that:
- The customer intentionally created an account and signed up for the service.
- The customer actively used the service after sign-up.
- The customer was aware of the recurring billing terms.
- 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 via the Enrich Dispute endpoint):
| 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 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.
Send activity logs via the dedicated User Event Log endpoint: POST /public/2025-04-01/disputes/{disputeId}/user_events_log, with source_id, account_id, and an events array (each event: name, date, and optionally id, ip_address, user_agent).
Tip
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 event types
| Event | Explanation | Importance |
|---|---|---|
| Sign up | Customer sign-up data including timestamp, IP address, and device information | Proves the customer is familiar with the merchant and their service or product |
| Login | Customer login data including timestamp and IP address; send multiple login events when available | Proves the customer intentionally used the merchant's service or product |
| Purchase | Customer purchase data for the service or product; send multiple purchase events if available | Strengthens the case by establishing that the customer knows the merchant, is familiar with the service quality, and authorized the transaction |
Example: sending activity logs
{
"source_id": "du_123456789",
"account_id": "act_112233",
"events": [
{
"name": "sign_up",
"date": "2024-01-15T08:22:00Z",
"ip_address": "203.0.113.42",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)"
},
{
"name": "login",
"date": "2024-02-10T14:05:00Z",
"ip_address": "203.0.113.42"
},
{
"name": "login",
"date": "2025-01-25T09:12:00Z",
"ip_address": "203.0.113.42"
},
{
"name": "purchase",
"date": "2024-01-15T08:25:00Z",
"ip_address": "203.0.113.42"
}
]
}Customer communication
A screenshot or record of customer interactions with your support team, especially conversations where the customer acknowledged the service, asked for a refund, or where you offered resolution, is highly effective evidence.
Two options:
- Structured messages: Use the Customer communication endpoint to send individual messages from your helpdesk programmatically.
- File upload: Use the Upload evidence endpoint with
evidenceUploadCategory: "customer_communication"to attach a screenshot.
How to send this data
Each data type has a dedicated endpoint:
| Data | Endpoint |
|---|---|
| Subscription record | POST /public/2025-04-01/disputes/{disputeId}/subscription (required: source_id, created_at, start_date, frequency, frequency_count) |
| Activity logs | POST /public/2025-04-01/disputes/{disputeId}/user_events_log |
| Order and transaction context | PATCH /public/2025-04-01/disputes/{disputeId} |
See the Enrich a Dispute guide for upsert semantics and array merge behavior.