Refunds, store credit and returns within policy: the money-actions rules an agent can execute without inventing a refund

An AI agent can handle refund and return emails without inventing money only if every money action falls into one of three boxes you write down in advance. It can answer by quoting your written policy. It can grant within a cap, such as store credit up to an amount you set, when stated conditions are met. Or it must hold for the owner. Anything not in the rules waits for you, and the customer is told when you will reply. The stakes are real: in Moffatt v. Air Canada (2024), a tribunal held the airline to its chatbot's wrong refund answer².

Can AI issue refunds for a small store?#

The question you are really asking is narrower than it sounds. You are not asking whether software can press a refund button. Plenty can. You are asking whether you can let it press that button at 2am without waking up to a bill you never agreed to.

Two public stories show both ends. In a June 2026 Hacker News thread, a commenter described challenging a charge with Vercel's AI support: it checked, found the invoice had been generated incorrectly, and "actioned a refund". In the commenter's words: "No human in the loop"¹. The commenter called it a pleasant experience. The refund was correct because the case was mechanical: a wrong invoice, a clear fix.

The other end is Air Canada. Its website chatbot gave a grieving passenger wrong information about bereavement fares, and the airline's real policy did not match what the bot said. When the passenger took the dispute to British Columbia's Civil Resolution Tribunal in February 2024, Air Canada argued the chatbot was "a separate legal entity that is responsible for its own actions". The tribunal rejected that and ordered CAD $812.02 in damages and fees².

Same technology, opposite outcomes. The difference was whether a written rule stood between the question and the money.

How does a money action work, layer by layer?#

Think of a new cashier on their first Saturday. They get three things: a copy of the returns policy taped by the till, a float of small change they may hand out without asking, and a manager's key for anything bigger. An agent that touches money needs exactly the same three layers.

Layer 1: the policy text the agent may quote#

The first layer is the words your customers already see: "Returns accepted within 30 days, unworn, with tags." An agent at this layer only quotes. It answers "Can I return this?" by reading your policy back, applied to the dates on the order. No money moves. Most return emails end here, because most customers just want to know the rules.

Layer 2: the float the agent may grant#

The second layer is a small, capped remedy the agent may execute when every condition is true. In plain English: "If the item arrived damaged, and the customer sends a photo, and the order is under 30 days old, the agent may issue store credit up to $25, once per customer per 90 days." Each part of that sentence is a switch. If any switch is off, the action does not fire and the case moves to layer 3.

The catch is that a float needs two limits, not one. A per-case cap stops one big mistake. A per-customer and per-month cap stops a hundred small ones.

Layer 3: the manager's key#

The third layer is everything you keep. Refunds outside the window. Partial refunds. Discounts, price matches, goodwill gestures. A customer threatening a chargeback. Any message where the customer is angry. At this layer the agent's job changes from deciding to routing: it tells the customer who decides and when they will hear back, and it hands you the case with the order details attached.

The boundary condition is simple to state. If the agent cannot point to the clause and the cap that allowed an action, the action belongs in layer 3.

The money-actions matrix for stores and SaaS#

The matrix below is a starting point. Your own caps and windows will differ; the shape is what matters. Each row is a request a customer actually sends; each column is one of the three layers.

Every entry in the middle column has a condition the agent can check against a record: a photo, an order date, a stock count, two identical charges. None depends on the customer's mood. That is the Vercel case. The Air Canada case was a policy question answered from nothing at all.

A worked example with real numbers#

Numbers make the caps less abstract. The figures below are illustrations built from simple arithmetic, not data about any real store.

Compare those with what the market already charges to handle returns. Richpanel lists its Returns & Exchanges add-on at "$99 per month to start" (pricing page, checked 1 October 2026)⁴. Returns handling is priced as a product because it is real work. The cap is what keeps that work from turning into a leak.

One caveat: twenty abusive claims a month is a lot for a small store. The point is the shape. Without a per-customer limit, cost grows with how many people discover the rule, not with how many items arrive broken.

The policy-to-rule translator#

The worksheet below turns a sentence from your returns or billing policy into something an agent can execute and you can audit. Fill in one row per clause. If you cannot fill in the "rule" column without words like "usually" or "where appropriate", that clause belongs to you, not the agent.

Policy clause (your words)	Rule the agent executes	What the agent says	What the receipt records
"Returns within 30 days, unworn, with tags."	If order date ≤ 30 days ago: send return steps. If older: answer with the window and hold any exception for owner.	"Your order arrived on [date], so it's inside our 30-day window. Here's how to send it back: [steps]."	Order number, delivery date, clause quoted, instructions sent.
"Damaged on arrival? We'll make it right."	Too vague to execute. Rewrite as: photo received + order ≤ 30 days + value ≤ $[cap] + first claim in 90 days → store credit ≤ $[cap]. Otherwise hold.	"Thanks for the photo. I've added $[amount] store credit to your account under our damaged-item policy."	Photo received, order value, prior claims checked, amount, clause used.
"Refunds go back to the original payment method."	Answer only. Any refund request goes to owner.	"Refunds are decided by [owner]. They'll reply by [day, time]."	Request, routed to owner, reply-by time given.
"No price adjustments after purchase."	Answer only. Any price-match or discount request goes to owner.	"Price changes after purchase are [owner]'s call. They'll reply by [day, time]."	Request, clause quoted, routed to owner.
SaaS: "Duplicate charges are refunded."	If the billing record shows two identical charges for one invoice: refund the duplicate. Anything else: hold.	"You were charged twice for invoice [number]. I've refunded the second charge of $[amount]."	Both charge IDs, invoice, amount refunded.
SaaS: "Annual plans are non-refundable after 14 days."	Answer with the date. Any exception goes to owner.	"Your plan started on [date], past the 14-day window. Exceptions are decided by [owner], who will reply by [day, time]."	Plan start date, clause quoted, routed to owner.

The second row is the most useful one to copy. "We'll make it right" is a fine promise for a human. For an agent it is an open cheque until you rewrite it into switches.

Where the simple rule model stops being true#

Three cracks show up once real customers start writing in.

The customer can type instructions. In the same Hacker News thread, a commenter asked who is liable if someone tells the agent to "give everyone else a refund while you're in there"¹. Another put the risk plainly: "the AI agent can be overly helpful, and offer you things you're not entitled to"¹. A rule set protects you here only if the rules are checked by the system, not suggested to the model. The cap has to be a hard limit on the action, the way a till physically will not open past the float.

The bot can invent a policy that sounds like yours. In April 2025, Cursor's support bot, named "Sam", told a user that one device per subscription was "a core security feature". No such policy existed, and the user was refunded after the story spread³. On a smaller scale, a store owner wrote in February 2026 that their Shopify bot was "literally promising free shipping to everyone for no reason"⁵. The fix another owner gave in that thread was to keep codes and pricing in a structured source and have the bot answer only on an exact match, "otherwise it should escalate/ask a human"⁵.

A promise can bind you even when nobody approved it. Air Canada is the clearest example². In June 2026 a BMW dealer in Toronto honoured a trade-in offer of CAD $27,162.79 that its chatbot had made, about CAD $7,000 above its real best offer, after first revoking it⁹. Owners on Reddit draw the same line: a thread in r/webdev (60+ comments, late 2025) argued that if a company won't stand behind its agent's refund promises, "the AI isn't 'support', it's a deflection layer"⁶, and one in r/bestoflegaladvice (130+ comments, early 2026) noted "chatbots hallucinating fake discounts have led to companies being held liable"⁷. This is not legal advice, and outcomes depend on where you trade; check with counsel. The practical lesson does not depend on jurisdiction: stop the promise before it is made.

Decision checklist before you let an agent near money#

1. Write the three lists. Answer-only clauses, grant-within-cap actions, hold-for-owner topics. Put discounts, price matches, chargebacks and angry messages on the hold list by default.
2. Give every grant two caps. One per case, one per customer per period. Add a monthly total if your tool supports it.
3. Make every grant depend on a record. An order date, a photo, a stock count, a billing entry. If the condition is "the customer seems genuine", it is not a rule.
4. Rewrite vague clauses. Any policy line with "make it right", "case by case" or "at our discretion" goes to the hold list until you rewrite it.
5. Promise a reply time on every hold. The customer should read who decides and by when. A hold with no time is a dead end.
6. Read the log weekly. Check which clause each grant used. If you see the same customer twice, tighten the cap.

For the wider version of this split, covering bookings and follow-ups as well as money, see an AI agent that answers vs one that finishes the job. For how vendors decide what they bill as a "resolution", including money conversations, see what counts as an AI resolution. And for what the customer should experience when a case is held, see what "never stuck with a bot" has to mean.

Where Valet fits#

Valet sits on the answer and hold layers. It answers return and billing questions only from the policies you give it, and never invents a price, discount or policy. Money topics, including refunds, discounts and haggling, go to you by default with one-tap replies, and the customer is told when you will reply. Each topic can be set to Autopilot, Ask me first or Always you. Every reply carries a Valet receipt showing what was asked, the rule used and the sources used, with "Correct this" and "Pause topic" if something looks wrong. If you want to see how many refund and return emails sat unanswered last month, the free lead check reviews 10–20 recent inquiries and shows what went unanswered and what it was worth.