Agent Payment Records: What to Keep Before a Dispute
A manager says she never approved your agent’s purchase. Which records would let you check?
IN 30 SECONDS
An authorization record is the set of linked traces behind an agent payment: who authorized it, what it could spend and what happened. It supports a review; it doesn’t assign liability.
KEY TAKEAWAYS · 3
- A useful authorization record links the principal, the allowed action and the actual result. It supports a review; it doesn’t assign liability.
- Two payments can settle the same way through x402; only a kept delegation record shows who approved one.
- Don’t wait for ERC-8203 (Draft, open PR #1614, not merged): give agents that move money an identity and a scoped account now.
On this page
My proposal: three records for every agent payment
IN SHORT Link who authorized the agent, what it could spend and what actually happened, so a disputed payment can be reviewed step by step.
WORDS TO KNOW
- Principal
- The person or organization an agent acts for, who gave it the power to spend.
- Delegation
- A principal giving an agent permission to act, within limits such as a task, a budget or an end date.
- Liability
- Legal responsibility for a loss. The facts, the contracts and the applicable law decide it, not the payment code.
This is a proposed integration, not a deployed product. One record per question: the Principal The person or organization an agent acts for, who gave it the power to spend. See the glossary, the limit, the payment.
IN PLAIN WORDS
Together, the three records make the evidence of Delegation A principal giving an agent permission to act, within limits such as a task, a budget or an end date. See the glossary stronger; a missing scope weakens it. That doesn’t mean no one can be legally responsible: what the records mean in law is a separate question.
Coming up next: So what changes when one record is missing?
A worked example: one payment, two records
IN SHORT The same small payment is easy to review when the delegation was written down, and hard when only the payment exists.
A WORKED EXAMPLE
Illustrative numbers
PASSThe ops team’s agent buys one report, delegation kept
INPUT
- Principal
- ops team
- Delegation
- market reports, cap 20.00 USD a month
- Spent so far
- 6.60 USD
- Price asked
- 0.05 USD
WHAT HAPPENS
- The agent presents a claim naming the ops team as its principal.
- The smart account checks the cap: 6.65 USD stays under 20.00 USD.
- The payment is signed and settled through x402.
- The app stores the delegation ID beside the settlement result.
OUTPUT
- Record
- principal + scope + result, linked
- Who approved it?
- ops team, delegation D-12
GAPSame payment, no delegation record
INPUT
- Principal
- unknown
- Delegation
- none written down
WHAT HAPPENS
- The wallet signs and the payment settles normally.
- The report arrives. Nothing links the payment to a task or a budget.
OUTPUT
- Record
- signed payment + settlement only
- Who approved it?
- open question
Both payments settle the same way, and x402 sees no difference. What the application kept is the whole difference.
The complete record tells a reviewer where to look.
Coming up next: So where does your system stand today?
What you can do today, before the standard is final
IN SHORT Don’t wait for ERC-8203, a Draft in open PR #1614, not merged. Give agents that move money a real identity and a scoped account now.
WHERE DOES YOUR SYSTEM STAND?
Step 1. Disputed payment. One question decides where you stand.
- Disputed payment One question decides where you stand.
- All linked All three are linked: the evidence is ready for review.
- Scope missing Scope missing: find the approval and what authority it granted.
- Payment only Payment only: who approved it stays an open question.
Then ask: what proof could your app show for a disputed payment? Check the payment scheme and any identity or receipt extensions, then write down what your rules must record.
WATCH OUT
Use reviewed code and explicit permission rules. Real code for this integration must check that the delegation is genuine, tie each payment to one asset and one recipient, block replays (one signed payment used twice), handle expiry and revocation, and check the off-chain condition.
ERC-8203 is still a Draft in open PR #1614, not merged. I wrote its reference implementation so people could discuss it with real code. Test against one pinned version.
ITEM GET
Keep the approval yourself
Sources: x402 payment authorization (HTTP 402), ERC-8203 draft, open PR #1614, not merged.
FAQ
A transaction alone doesn’t decide that. It depends on the parties, what they agreed, what power was delegated, what went wrong and which law applies. This is an engineering model for evidence, not a rule for who is liable.
Yes, as the second of three named authors; I wrote its reference implementation, and Xianrui Qin is the primary author. Treat it as work in progress, not something to build against today.
STAGE CLEAR
What you now know
- A reviewable agent payment links three records: who authorized it, what it could spend, what happened. They support a review; the facts, the contract and the law decide liability.
- Without a delegation record, who approved a payment stays an open question, even when it settled.
Check yourself
Tap or click a question to see the answer.
Your agent’s x402 payment settled with a valid signature. A manager says she never approved it. Which record could show whether she did?
The delegation record linked to the payment, if one was kept. The signature and settlement only prove the wallet signed and the payment went through.
Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.
Have a project to ship or a role to fill?
Discuss your project or roleFollow the engineering notes
Get new articles on production AI and smart contracts by email.