Building an AI Digital Worker for Refunds and Chargebacks

Part of my series on AI in production. Earlier parts covered evals, making agents safe to leave running, where people belong in the loop, and measuring ROI honestly. This one is about what I'm building now: an AI digital worker that handles refunds and chargebacks.

Refunds and chargebacks look like simple work. A customer asks for their money back, or their bank disputes a payment, and someone decides what to do. In practice, every case means opening four or five systems: the order, the payment, the policy, the customer's history and the CRM. The decision itself often takes a minute. Gathering what you need to make it takes much longer.

That makes it a good job for an AI digital worker, and a dangerous one. Good, because the work is repetitive, rule-based and well recorded. Dangerous, because the output is money leaving the business. A wrong answer here isn't a bad paragraph; it's a payout you can't take back.

At Prodaptix, I'm building a digital worker that handles this end to end: it validates each request against policy, executes the payout through the ledger, and logs every step in the CRM. Here is how it works, and what years in payments taught me about building it.

What the digital worker does

Every case follows the same path:

1. Gather the context. The order, the payment, earlier refunds, the customer's history and any messages, pulled together before anything is decided.
2. Validate against policy. Is the request inside the refund window? Does the amount match what was paid? Has this order already been refunded? Is there a pattern that needs a closer look?
3. Decide the route. Clear cases inside policy go straight to payout. Anything outside policy, unusual or above a set amount goes to a person, with the evidence already gathered.
4. Pay through the ledger. The payout is executed as a ledger entry with an idempotency key, never as a direct edit to a balance.
5. Log it in the CRM. The decision, the policy rule applied, the evidence and the outcome are written back where the support team already works.

The model does the reading and the reasoning. The rules, the ledger and the approvals do the deciding about money.

The model reads; the rules decide

The first design choice was where the model's judgement stops. Language models are very good at reading a messy customer message, matching it to an order and summarising what happened. They are not a policy engine.

So policy lives in code, not in the prompt. The model extracts the facts: which order, which item, what the customer is asking for, and why. Deterministic checks then apply the rules: the refund window, the amount, duplicates, limits. If the model misreads a message, the checks catch the mismatch with the order data instead of paying out on a misunderstanding.

This split also makes the system explainable. Every decision can be traced to a named rule, not to "the model thought it was fine."

Payments discipline, applied to an agent

In an earlier part of this series, I argued that payments solved the hardest problems of unattended agents decades ago. A refund worker is where that stops being theory.

• Idempotency on every payout. Each refund carries a key derived from the case and the order. If a step times out and the worker retries, the ledger returns the first result instead of paying twice.
• Record intent before acting. The worker writes "about to refund this order, key X" before it calls the ledger, so an interrupted run knows exactly where it stopped.
• Append-only history. Nothing is edited. A wrong refund is corrected with a new, linked entry, and the full trail stays visible.
• Limits and velocity checks. Caps per case, per customer and per day. A sudden spike in refunds pauses the worker automatically.
• Daily reconciliation. What the worker believes it paid is checked against the ledger and the payment provider every day. Any break goes to a person.

None of these make the model smarter. They make it safe to let the worker run.

Chargebacks need evidence, not just a decision

Chargebacks are different from refunds. The bank has already pulled the money back, and the question is whether to accept the dispute or fight it with evidence, usually against a deadline.

Here the worker's main job is assembling the case: the order, delivery or usage records, customer communication, and the policy the customer agreed to. It drafts the response and flags which evidence is strong and which is missing. A person decides whether to submit. The time saved is in the gathering, which is where most of the effort used to go.

Where people stay in the loop

Following the approach from the approval article, oversight is set per action, not per worker:

Each approval screen shows the exact payout, the rule applied and the evidence, and highlights what's unusual. Every approval, edit and rejection is stored and fed back into the eval set, so the next version is tested against the cases people actually corrected.

How it's tested

Before the worker touches real money, it runs against a set of past cases with known outcomes: clear approvals, clear rejections, duplicates, edge cases and the tricky ones the support team remembers. It's measured on whether it reached the right decision, applied the right rule, and asked for help when it should have.

Any change to prompts, rules or tools runs against that set first. A worker that pays out correctly but can't say why doesn't pass.

The goal is trust, not autonomy

It's tempting to judge a digital worker by how much it does on its own. For work that moves money, I think the better measure is whether, at the end of each day, you can say exactly what it paid, why, and prove that nothing happened twice.

Autonomy follows from that. Action types that keep passing reconciliation and approvals without edits move to lighter oversight. Anything that starts to slip moves back.

AI and payments only matter once they're trusted in production. A refund worker is a very direct test of that.