# Auto-triage Zendesk refund requests against Checkout.com

> Every 30 minutes we check new refund tickets against the real payment record, settle the small clear-cut ones, and escalate the rest to your team.

- Workflow type: agent
- Services: Checkout.com, Zendesk, Slack
- Categories: Customer Support, Finance
- Published: 2026-08-14

## What it does

- Checks your helpdesk every half hour during business hours for open tickets asking for a refund, and reads the whole conversation to work out who the customer is, what they bought, and why they want their money back.
- Finds the matching transaction in your payment records and confirms what was actually charged, whether it was completed, and whether any of it has already been paid back, so the same refund never goes out twice.
- Refunds the small, clear-cut requests on the spot inside the limits you set, replies to the customer, and logs the payment reference and amount on the ticket for your records.
- Escalates anything that is too large, too old, already refunded, or too vague to a Slack channel with the ticket link, what the customer asked for, what was found, and a clear recommendation, so a person makes the final call.

## What you'll need

- A Zendesk account with agent access to read and reply to tickets
- A Checkout.com account with permission to view payments and issue refunds
- A Slack workspace and a channel where your payments or finance team can pick up escalations
- An agreed refund policy: how many days after purchase you will still refund, and the amount below which a refund can go out without a human approving it

## Prompt

Every 30 minutes during business hours (default: every 30 minutes, 9am to 6pm, Monday to Friday, in my account timezone), triage new refund requests sitting in Zendesk against the real transaction records in Checkout.com, so my support team stops looking up and processing every refund by hand.

Start with Zendesk Search Tickets to find open or pending tickets that are asking for a refund (search the ticket text for refund language such as refund, money back, chargeback, or cancel and refund). Exclude any ticket already carrying the tag refund-triaged, so a ticket is never worked twice on a later run. For each ticket that comes back, use Show Ticket for the requester and ticket metadata and List Ticket Comments to read the full thread.

From the thread, pull out three things: the customer email address, the order or payment reference they cite, and the reason they are asking. Also work out the amount they are asking for and whether it is a full or partial refund. If the thread genuinely does not identify a transaction, do not guess.

Look the transaction up in Checkout.com using Search Payments against the order reference first, falling back to the customer email if there is no reference. Confirm the match with Get Payment Details to read the amount, currency, status, and creation date. Payment ids are prefixed pay_ and customer ids cus_. If Search Payments returns several plausible payments and none is a clear match, treat the ticket as unidentified rather than picking one.

Before deciding anything, call Get Payment Actions to list the authorization, capture, refund, and void actions on that payment. Add up every refund action already recorded. This is the guard against issuing a duplicate refund, so treat it as mandatory: if the payment is already fully refunded, or the existing refunds already cover what the customer is asking for, do not refund again.

Then apply the refund policy. Auto approve and issue the refund only when all of these are true: the payment status is captured, the payment date is inside the refund window (default 30 days), the refund amount is under the auto approve threshold (default 100 in the account currency), and the ticket clearly identifies exactly one transaction.

Be careful with amounts. Checkout.com expresses amounts as integers in the currency's minor unit, so 1000 means 10.00 GBP. Zero-decimal currencies such as JPY and KRW use the major unit directly, and three-decimal currencies such as BHD, KWD, and OMR are the value times 1000. Convert the auto approve threshold into the same minor unit as the payment before comparing, otherwise the threshold check will be wrong by a factor of 100.

When a refund is approved, issue it with Refund a Payment and send an Idempotency-Key header derived from the ticket id and payment id so that a retry can never double refund. This call returns 202 Accepted with an action id and is processed asynchronously, so the response does not confirm settlement. Confirm the outcome by calling Get Payment Actions again and reading the status of the new refund action.

For an approved refund, use Update Ticket twice over: post a public reply to the customer confirming the refund has been issued and telling them to expect it in 5 to 10 business days back on their original payment method (do not claim it has already landed in their account), and add an internal note recording the payment id, the refunded amount and currency, the refund action id, and the policy reason it qualified for auto approval.

Do not refund when the amount is over the threshold, the payment is already refunded in full or in part covering the request, the payment is outside the refund window, the payment is not captured, or the ticket does not clearly identify a transaction. In those cases leave an internal note on the ticket via Update Ticket explaining what was searched and what was found, then send a Slack message to the payments channel (default #payments) containing a link to the ticket, what the customer asked for, what was found in Checkout.com including the payment id, amount, status, date, and any existing refunds, the specific reason it was not actioned automatically, and a clear recommendation so a human can make the call quickly.

Finally, whichever path was taken, tag the ticket refund-triaged with Update Ticket so the next scheduled run skips it. Zendesk overwrites the whole tag array on a ticket update, so read the existing tags and write them back along with the new one rather than replacing them. Zendesk's search index also lags writes by a few seconds, so rely on the tag rather than on search freshness to avoid rework, and skip any ticket already tagged even if search returns it again.

## How to customize

- Change how often it runs and which hours count as business hours, for example every 15 minutes, or once an hour overnight too.
- Set your own auto approve amount and refund window, or set the amount to zero so nothing is ever refunded automatically and every request just comes to Slack with a recommendation.
- Choose which Slack channel gets escalations, and adjust the wording of the customer reply to match your brand voice.

## FAQ

### Could this accidentally refund the same customer twice?

No. Before issuing anything it pulls the full history of that transaction and adds up everything already paid back. If the payment has been refunded in full, or a partial refund already covers what the customer is asking for, it stops and sends the request to Slack instead of refunding again. Retries are also protected, so a hiccup in the connection cannot send the same refund twice.

### What happens to refunds above the auto approve amount?

Nothing is charged back automatically. The workflow still does all the digging, then posts to your Slack channel with a link to the ticket, the amount the customer wants, what it found in your payment records, and a recommendation to approve or decline. A person clicks through and makes the call.

### What if the customer never mentions an order number?

It tries the email address on the ticket first. If it still cannot confidently match the request to a single transaction, it will not guess. It leaves a private note on the ticket explaining what it looked for and sends the ticket to Slack for a human to identify.

### Will the customer be able to tell this was automated?

The public reply is written in normal, warm support language and does not announce itself as a bot. You can edit the wording to match how your team already writes. The technical details, such as the payment reference and the exact amount, go into a private internal note that only your agents can see.

### Does it work if we use a currency like Japanese yen?

Yes. Currencies record amounts differently behind the scenes, and the workflow is built to handle that so your auto approve limit means what you think it means rather than being off by a factor of a hundred.

Use this prompt in General Input: https://www.generalinput.com/prompts/auto-triage-zendesk-refund-requests-against-checkoutcom