Refunds and disputes in agentic payments

Start with outcomes

Technical finality is not commercial finality

Agentic payments can settle correctly on a rail while failing commercially. The merchant may not deliver, the resource may be unusable, the agent may buy the wrong variant, or the final terms may differ from the approved order. Rail finality describes what can happen to the payment instruction. Commercial finality includes fulfillment, cancellation rights, refund policy, dispute rights, and the principal's acceptance of the result. Systems must represent both rather than labeling an irreversible transfer as an unqualified success.

Recourse begins with the original authority and order evidence. Was the transaction within mandate? Did the seller receive the exact order the principal authorized? Did the rail settle the expected amount and asset? What was delivered, when, and under which return terms? Without that joined record, an agent can submit a support request but cannot prove why remediation is due. The receipt should expose deadlines and next actions before rights expire.

A settled payment can still be an unresolved obligation. Finality belongs to a rail; satisfaction and recourse belong to the commercial relationship.

Model remediation according to the payment rail

Card systems can support authorization reversal, merchant refund, and scheme-governed dispute processes, although exact rights depend on transaction, market, and network rules. Bank transfers vary widely in recall and dispute behavior. Onchain push payments are often technically irreversible; returning value generally requires a new compensating transfer from the recipient or another responsible party. x402 describes payment and settlement mechanics but does not create a universal refund or dispute regime for every paid resource.

The platform should expose these differences before authorization. An irreversible rail may be acceptable for a low-value machine resource with immediate verifiable delivery, but inappropriate for a high-value purchase with uncertain fulfillment. Policy can require refundable terms, human confirmation, merchant reputation controls, escrow-like mechanisms, or a rail with stronger recourse. Do not claim “instant finality” as an unconditional benefit while hiding the operational cost of correcting a bad outcome.

Give agents bounded post-purchase authority

An agent may monitor delivery, request a correction, cancel within terms, or accept a refund without exposing new funds. Other actions create new commitments: accepting store credit, paying return shipping, selecting a replacement with a higher price, waiving a claim, or sending a compensating transfer. The original purchase mandate should state which post-purchase actions are permitted. Otherwise the system must obtain step-up approval rather than assuming authority continues indefinitely.

Post-purchase agents should use the same deterministic control plane as checkout. They propose an action against the original order and evidence; policy evaluates scope, deadlines, amounts, destination, and legal or operational constraints. A refund destination should be verified against the original payment instrument or an independently approved destination. Attackers often exploit support flows because they appear less protected than payment initiation while still changing economic outcomes.

• Permit cancellation and refund requests only for the authenticated principal or an explicitly delegated agent.
• Bind every case to the original order, payment, fulfillment evidence, and applicable merchant terms.
• Require step-up before accepting materially different goods, store credit, fees, or waived rights.
• Verify refund destinations independently and reject instructions delivered only through untrusted conversation text.
• Record all offers, deadlines, approvals, submissions, responses, and credited amounts as append-only events.

Operate recourse as a case with deadlines and evidence

A recourse case needs an owner, reason, requested remedy, amount and asset, evidence set, submission channel, deadline, current state, and next action. Distinguish merchant support, processor refund, rail reversal, formal dispute, and compensating transfer; they are not interchangeable statuses. Partial refunds and multi-item orders require allocation back to line items, tax, fees, and accounting entries. A generic `refunded=true` cannot explain what was returned or whether the principal received it.

Close the case only after the remedial outcome is verified. A merchant's refund response is not the same as a credit on the rail, and an onchain return transaction must be checked for destination, asset, amount, and confirmation. Reconcile the credit, update the user-facing receipt, preserve the original failed outcome, and record any remaining loss. Trend reason codes to improve product and policy, but avoid interpreting a low dispute count as proof of satisfaction when users may have lacked a usable recourse path.

• Surface refund and dispute deadlines in user and operations views.
• Generate evidence packages from stored facts while requiring review for consequential representations.
• Authenticate inbound merchant and processor updates before changing case state.
• Reconcile approved refunds to actual credits and route missing credits to an exception queue.
• Use recourse outcomes to adjust merchant, rail, and mandate policy without silently rewriting history.