Chargeback Handling: The Seven Steps, and Who Decides Each One

A chargeback is a cardholder telling their bank that a transaction should not stand. The bank raises it with the network, the network raises it with you, and you have a fixed number of days to answer with evidence or lose the money.

The shape is the same at every card issuer. The reason code decides what evidence the network will accept, the deadline decides when you stop, and what varies between companies is which steps run on their own and which ones a person has to own.

The dispute workflow, step by step

This is the flow as it runs on Forest, from a declined refund request to a dispute marked won. Four of the seven steps call out to a system you already run.

Step 2 is where most of the time goes today, and none of it needs a person. The reason code is known when the dispute lands, and the reason code determines what the network will accept. Your reviewer should open a file that is already assembled.

Step 3 is the one that breaks the timeline. Some reason codes need a receipt or a written statement only the cardholder has, so the case waits with the deadline still running. Same mechanic as request for information handling, with less forgiveness: your customer has no reason to care about a network deadline.

Why disputes are the process teams automate first

Get KYC or AML wrong often enough and you are explaining yourself to a supervisor who can take your licence. Get a chargeback wrong and you are out the transaction amount and a fee.

So this is where teams send their first agent, and it becomes the proving ground for everything after it. The permission model, the approval thresholds and the audit format all get built here, on the process where a bad week costs money.

Where a person stays in the loop

Filing a response to the network is reversible, so it automates early. Refunding a customer moves funds, so it stays with a person. The threshold that decides which cases a person must see is enforced by roles and permissions rather than by a convention the team agrees to respect.

• One agent, one action. Give an agent one precise step and keep the rest a workflow. A qualification agent qualifies. Deciding and executing belong elsewhere.

• Challenges are the training signal. When a reviewer overrules a recommendation, that disagreement is the most useful output of the week. It only exists if the reasoning was visible enough to argue with.

• The trail covers both. Agent actions and human actions land in the same audit trail. A reviewer who approved an agent's filing is on the record exactly as one who wrote it.

The guard that closes the reply path

When a consumer has an open legal dispute with you, a well-meaning support reply about the transaction can be read back to you in court.

So the case carries a hard block. If a legal dispute is flagged on that customer, the reply path closes and the case routes to whoever is allowed to answer. The operator does not get the option and does not need to remember the rule, because the block is a property of the case rather than a line in a playbook.

The same mechanism handles the smaller version of the problem: an outsourced or offshore team that may work the case but may not export it, see the full customer record, or reply directly.

What you configure to run this on your own stack

The seven steps hold. Four things change per company.

• Trigger source. An in-app dispute form, a support conversation, a ticket, or network documents arriving inbound.

• Evidence map. Which records each reason code requires, so step 2 fetches exactly those.

• Refund threshold. The amount above which a person decides, and who that person is.

• Filing channel. Your acquirer or the network directly, and whether filing runs after human validation or on its own.

Everything else is the same workflow.

LEVEL UP YOUR OPS GAME. Every action traced, for every human, AI agent, BPO, LLM, and workflow. Book a demo.

Forest is the operational infrastructure regulated companies grow on.