Table of Contents
An agent wallet is a prepaid USDC budget, not a treasury. After it starts paying x402 APIs, you still have to match each spend to a service, a cost center, and a human principal.
How to set up an AI agent wallet gets the policy and the key out of the prompt. This page is the books after the first 402.
Key Takeaways
- Treat the agent wallet as a prepaid card: the USDC balance is a budget to close, not a treasury to manage.
- Do not use the on-chain hash as the primary key; Circle nanopayments can share one batch hash across many USDC spends.
- Persist the x402 requirement, PAYMENT-RESPONSE, nonce, service URL, amount, and policy decision before the wallet signs.
- Attribute every completed spend to a KYA principal and a cost center, not only to a wallet address.
- Broadcast is not paid: wait for a completed or confirmed status, and treat facilitator settlement_pending as a reconciling item, not a retry.
- Log policy refusals in the same ledger as successful transfers, or prompt-injection probes never show up in finance.
- A refund is a new outbound payment a human must approve; the agent must not undo its own USDC.
- Close the day on three balances: wallet USDC, any nanopayment float, and the GL, then kill the session if they do not match.
What agent spend reconciliation is
Reconciliation here is matching machine-speed USDC outflows to a human-readable ledger. Each row needs a buyer principal, a service, an amount, a policy result, and a settlement status.
It is not explorer-watching. A hash without a 402 payload is a transfer you cannot explain.
Why a transaction hash is not a receipt
x402 is the HTTP challenge. Circle Agent Nanopayments can batch many of those authorizations into one gasless settlement.
Circle's x402 transfer search returns a per-transfer id and a batch `txHash`. If you key the books on the hash, two API calls look like one purchase.
x402 itself does not replace receipts or accounting. The protocol moves USDC, and your ledger stores why.
Join three ledgers, not one explorer view
You need three records that close against each other.
| Ledger | What it knows | What it cannot tell you |
|---|---|---|
| Wallet / chain | Balance and settlement hashes | Which API the agent bought |
| Facilitator / nanopayments | Per-transfer status and batch hashes | Which cost center or principal owns the spend |
| Internal GL | Budget, cost center, KYA principal | Whether the 402 actually settled |
If any one of those is missing, you have a prepaid card with no statement.
Log the 402 before the wallet signs
Persist the payment requirement before the signer runs. Store the service URL, amount, scheme, network, and the policy decision that allowed or blocked it.
The x402 facilitator verifies the payload, then settles, then returns a PAYMENT-RESPONSE. If you only log after the 200, failed and refused spends never exist.
Do not let the model invent the receipt later. The 402 headers are the source document.
Match PAYMENT-RESPONSE to a cost center
When the response comes back, join it to the row you opened before signing. Attach the KYA principal, the agent id, and the cost center the budget came from.
Coinbase's x402 path for businesses is the merchant side of the same payment. Your books still have to say which team bought the call.
A wallet address is not a cost center. Two agents can share a budget and still need separate lines.
Pending, failed, and refused spend
Broadcast is not paid. x402's settlement_pending means the facilitator broadcast a transaction and could not confirm it yet.
Treat that hash as a reconciling item. Do not retry the same payload until you know it failed, or you can pay twice for one resource.
Log policy refusals next to successes. A blocked new beneficiary is a control working, not empty space.
Refunds are a new payment
On-chain USDC transfers do not reverse once they settle. A refund is a new outbound payment to a verified address.
The agent must not decide that payment. A human approves the refund the same way they would for an invoice overpay.
Close the day and kill the session
Close three numbers: wallet USDC, any Gateway nanopayment float, and the GL total for that agent. If they do not match, freeze the session before you add budget.
Then revoke session authority. A wallet that is "almost reconciled" is still a live spender.
When not to keep the agent funded
Skip a funded wallet if you cannot write an allowlist and a cost-center map. Spend you cannot attribute is a write-off with extra steps.
Skip it if the job is one human invoice. That is accounts receivable, not machine AP.
Skip it if you need the chain explorer to be the ERP. Gasless batches and pending settlements will lie to you.
FAQs
Why can't I just match the transaction hash?
Circle nanopayments can put many USDC spends under one batch hash. The primary key is the per-transfer id plus the 402 you stored before signing.
What is settlement_pending?
The facilitator broadcast an EVM settlement and could not confirm the receipt yet. The hash may still confirm, so treat it as open, not as a failed retry.
What do I log when policy blocks a payment?
Log the requirement, the reason, the principal, and the timestamp. Finance needs to see the refusals or it cannot see the attack.
Who owns a refund?
A human. A refund is a new USDC payment, and the agent should not send it.
How is this different from invoicing in stablecoins?
Invoicing is a client paying you. Agent spend is you paying APIs from a prepaid USDC budget, often in sub-cent batches.
Disclaimer:
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy, sell, or hold any financial instrument, and readers should conduct their own independent research or consult a qualified professional.
){kind=link}