How to use Zendesk tickets as chargeback evidence

When a subscriber disputes a charge, your support history is often the strongest evidence you have. A ticket where the customer asked a question about the product after the renewal, or a ticket where you confirmed their cancellation and refunded them, can decide the case. A ticket that was paraphrased, redacted badly or exported without dates is worth much less.

This guide covers what makes a Zendesk ticket useful as evidence, how to set up fields and macros so the right facts are captured at the time, and how to get tickets out of Zendesk in a form a card network reviewer can read. Zendesk features come from Zendesk’s own documentation: printing tickets, exporting data, custom ticket fields, macro actions, redaction and the Ticket Audits and Ticket Comments APIs. Dispute fields come from Stripe’s dispute categories and evidence best practices (all accessed November 2026).

What a reviewer is looking for

A dispute is decided by someone at the card issuer who has never heard of your product and has a few minutes to read your file. For subscription disputes, the questions are usually simple:

• Did the customer know they would be charged?
• Did they try to cancel, and if so, when, and what happened?
• Did they keep using the service after the charge?

For the “subscription canceled” category, Stripe’s dispute categories page points you to the cancellation_rebuttal field (why the subscription was not cancelled, or why the charge is still valid) and customer_communication (correspondence showing the customer kept using the service or knew about the renewal). Stripe’s best practices recommend combining several communications, such as emails and chat transcripts, into a single file for that field.

A Zendesk ticket can answer all three questions, if it has three things.

The three things that make a ticket evidence

1. Timestamps you can trust

Every comment in Zendesk carries its own creation time, and Zendesk keeps an audit trail. The Ticket Audits API describes audits as a read-only history of all updates to a ticket, each with its own created_at. That matters: a dispute often turns on whether the customer wrote before or after a renewal date.

When you present a ticket, show the date and time of every message and state the time zone. Zendesk’s data export page notes that CSV timestamps use the account’s default time zone; your billing provider may use UTC. Put both on the same basis before you build a timeline.

2. The customer’s own words

Quote, don’t paraphrase. “Customer confirmed they were using the reports feature” is your opinion. A dated message from the customer’s email address saying “the export in reports is broken again, can you fix it before our board meeting” is evidence.

Keep these rules:

• Quote the full message, or a clearly marked excerpt with “[…]” where you cut.
• Never correct, summarise or translate inside the quote. If you translate, give the original next to it.
• Include messages that hurt your case if they are relevant. A reviewer who finds an omitted cancellation request will not trust the rest of the file, and submitting a misleading file is not something you should do anyway.

3. A clear resolution

The ticket should show how it ended: cancelled on a given date, refunded, credit issued, question answered. If an agent cancelled a subscription, the ticket should say so in a public reply to the customer, not only in an internal note.

Set up Zendesk to capture this at the time

Evidence is much easier to find when it was labelled the day it was created.

Custom fields

Zendesk’s custom ticket fields guide explains that admins add fields in Admin Center under Objects and rules > Tickets > Fields. Drop-down options each get their own tag. Useful fields for disputes:

Field	Type	Values
Billing request	Drop-down	Cancel request, Refund request, Charge question, Downgrade, None
Cancellation outcome	Drop-down	Cancelled immediately, Cancelled at period end, Customer withdrew request, Not applicable
Refund issued	Checkbox	Yes / No
Billing customer ID	Text	The ID from your billing system

Do not create a field for card numbers or full payment details. You never need them as evidence, and Zendesk documents automatic redaction of credit card numbers (Professional plans and above) for when customers paste them anyway. Per Zendesk, it keeps the first six and last four digits and does not apply to numbers already in the system; older ones have to be redacted manually, which is irreversible.

Macros for refund and cancel requests

Zendesk’s macro actions can set drop-down, multi-select and checkbox fields, and set, add or remove tags. A “Cancel request handled” macro could:

1. Post a public reply confirming the cancellation and the date it takes effect.
2. Set Billing request to Cancel request.
3. Set Cancellation outcome to the matching value.
4. Add a tag such as cancel_confirmed.

The confirmation reply is the important part. It turns “we cancelled it” into a dated message in the customer’s inbox and on the ticket. Keep the wording factual: what was cancelled, from when, and whether any refund applies.

Zendesk’s macro actions list covers tag-setting fields (drop-down, multi-select, checkbox), so plan on the billing customer ID coming from an integration or being typed by the agent.

Getting tickets out

One ticket at a time: print

Zendesk’s printing tickets article describes opening the ticket, clicking the Ticket options menu and choosing Print ticket. You can choose whether to include internal notes and side conversations (Suite Professional and above). For evidence, leave internal notes out unless they matter: they are written for colleagues and can read badly out of context. Print to PDF and check every message shows its date.

Many tickets: export or API

Method	Includes comments?	Notes from Zendesk’s docs
Admin Center data export, JSON	Yes	Off by default; the account owner asks Zendesk Support to enable it; comments are dropped for tickets over 1 MB
Admin Center data export, CSV	No	Ticket fields only; no comments or descriptions
View export to CSV	No	Fields of the tickets in a view
Ticket Comments API	Yes	Can be sorted by created_at
Ticket Audits API	Yes, with every change	Read-only history of all updates

Sources: data export, view export, Ticket Comments, Ticket Audits.

The CSV exports are useful to find the right tickets (filter on your Billing request field) but not as evidence on their own, because they leave out what the customer wrote.

Building the evidence file, step by step

1. Find every ticket from the disputing customer’s email address, and any other address on their account.
2. Sort all messages by time and place them on one timeline with billing events: signup, renewal notices, charges, cancellation.
3. Pick the messages that answer the reviewer’s questions. Quote them in full with date, time zone and sender.
4. Write a short cover note in plain language: “The customer contacted support on [date] about [feature], [N] days after the disputed charge. Full message below.”
5. Combine the transcripts into one file for customer_communication, as Stripe recommends.
6. Check nothing in the file contains card numbers or unrelated personal data.
7. Submit before the deadline shown on the dispute.

Doing this with NoChurn

NoChurn’s Zendesk connector is read-only: it reads tickets and never replies, tags or edits anything in Zendesk. Tickets are matched to your customers by email; doubtful matches are suggested for you to confirm and never merged automatically. When a dispute opens on Stripe or Braintree, NoChurn gathers the evidence automatically (cancel flow answers, emails sent, usage, and the matched Zendesk messages, quoted verbatim with their dates), drafts a reply with AI, and sends it only after you review it. Ticket handling, macros and redaction stay in Zendesk, and the dispute decision stays with the card issuer. See NoChurn + Zendesk.