How to let AI agents handle returns and refunds safely

Why refunds are the hard case

Reading an order status is harmless. A refund moves money. When a customer's AI assistant asks your business to return an order, everything that can go wrong with automation can go wrong with money attached: the wrong agent, the wrong amount, the same refund twice, a refund the customer never really agreed to.

The good news: each of those risks has a well-understood control. Here are seven.

1. Know which agent is asking

An agent's name in a request header proves nothing. Require each agent to authenticate with its own signing key (OAuth 2.0 private_key_jwt), and bind its session tokens to that key with DPoP, so a copied token is useless on its own. Keep new agents waiting for your review until you allow them, and keep a way to block any agent instantly.

2. Make the customer sign in with you, not with the agent

The agent should never see the customer's password. Use a device sign-in: the assistant shows a short code, the customer enters it on your page and signs in there, with their password or your identity provider. You decide who the customer is, and the customer can disconnect the assistant at any time.

3. Write rules per action, deny by default

Every action needs a rule, and anything without one is refused. For returns, a typical rule set:

• Up to $100: the customer approves in their assistant.
• Over $100: the customer approves, then your team reviews.
• Payments and payouts: refused until you have a dispute process.

4. Limit totals over time, not only per request

A per-request limit of $100 is easy to get around: ask for $99, three times. Add limits per customer over a window: no more than $150 in returns per customer per day, and no more than three returns per week. Count them across every agent, so switching assistants doesn't reset the counter.

5. Approve exact terms, not intentions

"Return my jacket" is an intention. "Return order 1042, refund $49 to the original card" is a term. The customer should approve the exact terms, and if anything changes after that (the amount, the method, the order), the old approval must no longer apply. Proposals that are never approved should expire.

6. Execute at most once, and never guess

Networks fail. If your system processed a refund but the answer was lost, a naive retry refunds twice. Two rules prevent that:

• Send every execution with the operation ID as an idempotency key, and have your system do the work at most once per ID.
• When the outcome is unknown, don't mark it failed. Retry with the same key, and if it still can't be learned, hold it for a person to check and settle.

7. Keep a record you can prove

Record every step: who asked, which rule decided, what the customer approved, what your system answered. Chain each record to the one before it and export signed checkpoints, so if the history is ever rewritten, the copy you kept will show it. And keep an emergency stop that halts every agent at once, including refunds that were confirmed but not yet sent.

Putting it together

A refund through a well-built gateway looks like this:

1. The assistant, signed in with its key, asks to return order 1042.
2. Your system quotes the exact terms: $49 to the original card.
3. Your rules check the amount and the customer's total for the day.
4. The customer approves those terms in their assistant.
5. Your system processes the refund once, with the operation ID as its key.
6. Every step is on a signed record you can export.

Allowfy provides all seven controls out of the box: agent identity, customer sign-in, rules with limits per request and over time, approvals of exact terms, at-most-once execution with unknown outcomes held for your team, a signed ledger, and an emergency stop. Your system answers four questions through a signed webhook, and the open-source allowfy package handles the signatures for you.

Start in test mode: everything runs end to end, and no money moves.