# Letting an AI pay for you: limits, previews and undo

By Bart Dunweg, Apr 21, 2026 · 7 min read

When an agent pays, books or refunds on someone's behalf, the interface leaves the screen. It becomes the limit, the preview, the record and the way back, which payments has always designed.

When an agent, an AI assistant that acts for someone, pays for something on their behalf, the screen where that person would have pressed the button disappears. The design work does not disappear with it. It moves to five places: the boundary of what the agent may do alone, the preview of what it intends to do, the limit it cannot cross, the record of what it did, and the way back. Get those right and nobody misses the button. Get them wrong and the first refund request is also the last time anyone lets the agent near a card.

Payment design has always been about the moment money leaves someone's account. Its patterns were built for a human pressing pay. Most of them survive the move to agents, but one of them, reversibility, moves from a support concern to the centre of the design.

## The button was doing more than it looked like

In a normal checkout, the pay button carries a lot of weight nobody writes down. It is consent, a last look at the total, and acceptance of the method, the merchant and the timing, all in one press. Much of what I wrote about [designing payment flows people finish](https://bartdunweg.com/articles/designing-payment-flows-people-finish) is about protecting that moment.

An agent removes the press, which is the point of it. But consent, review and acceptance still have to happen somewhere, and if the design does not place them deliberately, the person finds out what they agreed to from their bank statement. So the first question for any agent that touches money is not how it should act. It is where each thing the button used to do will live now.

## Autonomy is a budget, not a setting

The tempting design is a toggle: the agent may pay, or it may not. A toggle is the wrong shape, because the risk of a payment action is not one number. It depends on at least three things, and the boundary should be drawn along each of them.

### Amount

Small, frequent, predictable amounts are where autonomy earns its keep. Topping up a transit card is a different decision from booking a flight. A threshold the person sets, in their own currency, in a sentence they can read back, beats any clever default.

### Reversibility

Some actions can be cancelled for free, some can be refunded with effort, and some cannot be undone at all. A refundable booking and a non-refundable one at the same price are not the same risk, whatever the price says.

### Novelty

A repeat purchase from a merchant the person has paid before is low risk in a way a first purchase from an unknown merchant never is, whatever the amount. A new merchant, a new method, a new country: each is a reason to stop and ask, even inside a budget.

Inside the budget, the agent acts and reports. At its edge, the agent previews and waits. Outside it, the agent cannot act at all, and says so.

## The intent preview is the new checkout

When the agent reaches the edge of its budget and stops, what it shows has replaced checkout, and it deserves a higher standard than checkout, because the person did not assemble the order. They are reviewing someone else's work.

A useful intent preview answers, in this order:

- What will be bought, from whom, in plain words, with the merchant name as it will appear on the statement.
- The total, including everything that will be added, in the person's currency, with any conversion stated.
- Which payment method, and when the money will leave.
- Whether it can be undone, how, and until when.
- Why the agent stopped here instead of acting.

The fourth line is the one most previews leave out, and it decides how fast the person can approve. Someone told that a booking is free to cancel until tomorrow can say yes at a glance. Someone not told has to assume the worst and read everything, which is how approvals become a chore that people abandon or rubber-stamp. The fifth line makes the boundary legible, so the person can adjust the budget instead of guessing at it.

## Undo is a design problem first

Engineers will say, correctly, that undo for payments is hard: once money has moved, getting it back is a refund, a new transaction with its own timing and its own ways to fail. That is exactly why undo has to be designed before it is built. The design decides which actions are structured so that undo stays cheap.

Payments already has the vocabulary. A card payment can be approved without being collected: the bank reserves the money rather than handing it over. [Stripe's documentation on holds](https://docs.stripe.com/payments/place-a-hold-on-a-payment-method) uses the hotel as its example: reserve the full amount before the guest arrives, collect it at checkout. It also notes that an online card reservation usually lasts around seven days, after which the money is released if nobody collected it. Inside that window, cancelling is a release, not a refund. Nothing has to come back, because nothing has left.

That gap is where an agent's undo can live: reserve first, collect later, and the person has the whole window to change their mind at no cost. Not every method allows it: the same page lists iDEAL, the way most Dutch people pay online, among the methods that cannot reserve money without collecting it. An agent working in the Netherlands cannot assume the cheap undo exists, and has to say so in the preview.

So the order of work is: decide which actions must be cheaply reversible, choose the payment mechanics that keep them so, and only then set the autonomy for each. Undo is not a button on the record screen. It is a constraint on how the action was taken in the first place.

### When there is no way back

Some actions are final: a non-refundable ticket, a transfer to another person, a purchase from a merchant with no cancellation policy. These belong behind the limit, outside the autonomous budget whatever the amount, with the finality stated before acting, every time. An agent that can do something irreversible without pausing had its boundary drawn by someone who never answered the support ticket.

## The record is where trust is kept

After the agent acts, the person needs a record that reads like a statement, not a log. Every action, the amount, the merchant, the method, the time, and next to each one the state of its undo: cancellable until a stated moment, refundable through a stated process, or final.

The record also checks the boundary. Ten small purchases that each fell inside the budget can together be more than the person meant to allow, so a good record shows totals over time as well as items, and the budget gets adjusted against what happened rather than what was imagined.

It must never overstate, either. "Paid" and "requested" are different sentences, and a record that says the first before the merchant has confirmed will one day have to take it back.

## Where the design work has moved

Put together, the interface of an agent that spends money is not a screen with a button. It is five surfaces, each with one question to answer:

| Surface  | The question it answers                                |
| -------- | ------------------------------------------------------ |
| Boundary | What may the agent do without asking?                  |
| Preview  | What exactly is about to happen, and can it be undone? |
| Limit    | What can it never do, whatever the instruction?        |
| Record   | What did it do, and what state is each action in?      |
| Way back | How does the person reverse it, and until when?        |

The pay button was never the point. It was the last place a person could change their mind, and an agent that spends their money owes them that place back.