How do I record the inputs an agent used for a payment or identity decision?

What should I check, step by step?

1. Decide which decision you are proving: "pay this x402 requirement" or "accept this agent identity / reputation signal," and list the input fields that would change the yes.

2. Capture the raw Payment Required (or identity registration) bytes the agent actually received — not a paraphrased summary — and store sha256 (or keccak256 when you follow an on-chain scheme) of that byte string.
3. For identity: record agentRegistry, agentId, the agentURI/registration file hash, the block or fetch time you read it at, and whether endpoint-domain verification succeeded. ERC-8004's optional domain check is a separate fact from "the NFT exists."
4. For payment: record network, asset, amount (or upto max), payTo, resource/origin, scheme, any facilitator, and the idempotency or payment-identifier the client will reuse on retry.
5. Bind the spend authorization or human approval to those hashes (amount, payTo, resource, identity ids). Re-check the hashes immediately before signing; if the 402 or registration file changed, ask again.
6. Write the receipt outside the agent's writable session: server DB, append-only ledger, or a checkpointer the agent's tools cannot UPDATE. Give the agent only a receipt id.
7. After settlement, attach the chain tx hash (ERC-8004's proofOfPayment shape) to the same decision id so payment outcome and decision inputs stay one record.
8. Log denials and mismatches (payTo ≠ registered agentWallet, endpoint unlisted, policy deny) the same way you log allows — a missing deny is how silent retries rewrite history.

What "inputs" means for payment vs identity

A payment decision's inputs are the price quote and destination the agent accepted: x402's Payment Required body or header fields, plus any client-side caps (maxAmountPerPayment, cumulative spend) and the approval or spend policy that said yes.

• An identity decision's inputs are what you read about the counterparty before trusting or paying it: ERC-8004's globally unique (agentRegistry, agentId), the registration file (endpoints, x402Support, supportedTrust), optional endpoint-domain verification, and any reputation or validation summary you filtered by reviewer set (the ERC warns unfiltered summaries are open to Sybil/spam).
• ERC-8004 explicitly leaves payments to other protocols such as x402, and shows proofOfPayment inside off-chain feedback and a Validation Registry that commits to requestURI contents with requestHash — that is the same pattern as "hash the inputs, store the receipt."

Keep the record outside the agent's editable session

Anything in chat memory, AGENTS.md, or a workspace JSON file can be overwritten by the next turn or a prompt injection that claims "already approved."

• OpenAI's Agents SDK human-in-the-loop guidance keeps RunState snapshots in application-controlled server storage and never accepts replacement tool calls or serialized state from the browser client as authorization.
• LangGraph's persistence docs treat InMemorySaver as non-durable; production approvals belong in PostgresSaver/SqliteSaver (or an external ledger) on a thread id your payment runner owns.
• Practical pattern: payment runner loads receipt by id, verifies input hashes still match the 402/registration it is about to use, then signs; on mismatch it refuses and opens a new approval.

What can go wrong?

Only the tx hash is logged after the fact, with no hash of the Payment Required the agent signed for — you cannot tell whether payTo or amount was swapped mid-flight.

• Identity was copied from a directory UI into the prompt; the agent paid a different payTo than the registered agentWallet with no recorded mismatch check.
• The approval flag lives as approved=true in the agent's session and gets reused for a larger amount or a new resource.
• Retries mint a new payment authorization without consulting the original decision receipt (use one idempotency / payment-identifier per decision).