← Blog

What Happens When an AI Agent's Purchase Goes Wrong?

June 12, 2026 · Victor Young

When an AI agent's purchase goes wrong, what happens next depends entirely on where the money is. If the agent paid a merchant directly—card charged at checkout, funds captured immediately—you are in the same dispute process a human shopper faces, minus the order confirmation emails you never saw because the agent placed the order. If the purchase ran through an execution layer with escrow, the answer is structurally better: in most failure cases the money has not settled yet, so "getting it back" means releasing an authorization rather than clawing back a payment.

This article walks through the failure cases—wrong item, never shipped, damaged on arrival, agent simply bought something you didn't want—and what recovery looks like in each, with and without an execution layer.

The Core Problem: Settlement Speed vs. Verification Speed

Traditional checkout settles fast and verifies slowly. The card is captured in seconds; whether the right thing actually arrives gets determined days later. Everything painful about purchase disputes flows from that gap—the merchant has the money during the entire argument about whether they should.

Human shoppers absorb this gap manually: they read confirmation emails, watch tracking, inspect boxes. An agent placing dozens of orders amplifies the gap, because no human was watching each checkout happen. If agent purchases settle instantly, every agent mistake becomes a recovery project.

The fix is to make settlement wait for verification. With Firestarter's escrow model, approving a purchase authorizes the card, but funds settle only on delivery confirmation. The window where most things go wrong—sourcing, shipment, transit—is exactly the window where the money has not yet moved.

Case 1: The Supplier Never Ships

The simplest failure, and under escrow, the cleanest. If a supplier fails to generate a shipment within the expected window, the execution is flagged for exception handling: the order can be re-sourced from an alternative supplier or the execution cancelled. On cancellation the authorization is released—no capture ever happened, so there is no refund to chase, no dispute to file, no merchant support queue. The execution record shows the supplier, the timeline, and the outcome.

Contrast with the direct-checkout version: the merchant has your money, the agent has a confirmation number, and you have a customer-service ticket.

Case 2: The Wrong Item, or Damaged on Arrival

After delivery, you are in returns territory, and the supplier's return policy applies—escrow does not magically rewrite merchant policy. What the execution layer changes is the mechanics:

  • The evidence is already assembled. The execution record contains what was ordered (the exact listing), what was paid, when it shipped, and when it was delivered. A returns case that normally starts with twenty minutes of inbox archaeology starts instead with one queryable record. (This is the practical payoff of audit trails for agent purchases.)
  • The process is facilitated and recorded. Firestarter facilitates the return flow with the supplier and records each step in the execution log, so the return has the same traceability as the purchase.
  • Refunds reverse a known payment. The refund is issued against the Stripe payment intent tied to that execution—not "whichever card the agent used at whichever merchant."

For orders cancelled before delivery confirmation, no refund process is needed at all: the authorization is simply released, because no capture occurred.

Case 3: The Agent Bought Something You Didn't Want

The failure people fear most—the agent misunderstood, overreached, or got manipulated by a misleading listing—is the one the system is designed to make nearly impossible to complete.

Approval is the default. An execution pauses before payment, and a human reviews the specific item, price, and supplier. An agent that misunderstood produces a pending approval you decline in five seconds, not an order you unwind over a week. The purchase that "goes wrong" never goes at all.

If you have turned approval off for a category of purchases—legitimate for low-value, high-frequency restocks—two backstops remain. The per-execution spend limit bounds the worst case in dollars, including shipping. And escrow means even an unwanted-but-within-limit purchase has not settled until delivery; cancel before shipment and the authorization releases. The configuration trade-offs are covered in how to give your agent a budget and human-in-the-loop purchasing.

Case 4: Genuine Disputes

Sometimes the supplier insists they shipped the right thing and you disagree. Disputes between buyers and the network resolve against the execution record: the listing as it appeared, the approved amount, shipment events, delivery confirmation. Both sides argue from the same log. This is materially different from card-network chargebacks, where the evidence is whatever screenshots each side happens to have kept—and where agent-placed orders are notoriously weak, because "my AI placed this order" plays badly on a chargeback form. Sellers, for their part, get symmetric protection: settlement on delivery means a buyer cannot take delivery and then quietly reverse payment outside the dispute process. (Sellers: see selling to AI agents.)

What This Means for How Much You Delegate

The practical question behind all of this is not "can purchases be undone"—it is "what is my worst case if I let the agent run." Direct checkout answers: your worst case is your card limit and your patience with dispute processes. The execution-layer answer is concrete and configurable:

  • Before approval: worst case is a declined approval. Cost: nothing.
  • Approved, before shipment: worst case is a cancelled execution and a released authorization. Cost: nothing settled.
  • Shipped, before delivery confirmation: worst case is an exception flow—re-source or cancel—while funds are still unsettled.
  • After delivery: worst case is a normal return under the supplier's policy, with complete evidence.

Bound your downside with spend limits, keep approval on where stakes are high, and the failure cases stop being scary enough to block delegation. That—more than any model improvement—is what makes agent purchasing operationally boring, which is the goal.


FAQ

Can I cancel an order my agent placed?

Yes. Before shipment, cancelling the execution releases the Stripe authorization—no charge is captured. After shipment, cancellation becomes a return/refund flow under the supplier's policy, facilitated and recorded by Firestarter.

Who pays when an agent makes a mistake?

If approval was on, mistakes are declined before payment—nobody pays. If approval was off, the purchase is still bounded by the spend limit you set, escrow holds settlement until delivery, and pre-shipment cancellation releases the authorization entirely.

Do refunds cost extra tokens or fees?

No. Cancelled executions release the authorization without additional charges, and buyers pay no transaction fees. Refunds after capture are issued against the original Stripe payment intent.

How do I know what my agent actually ordered?

Every execution—item, supplier, amount, approval, shipment, delivery, receipt—is in the execution audit trail, queryable by API and visible in the dashboard. See AI agent audit trails.

Does escrow slow down my orders?

No. Escrow changes when money settles, not when orders ship. Suppliers ship on approved orders as usual; they are paid on confirmed delivery. Honest sellers are unaffected, and a 3% commission on completed sales is their only cost—listing is free.