After the Signature: Receipts, Settlement, and Audit for AI Agent Payments

The companion piece to Beyond the Wallet. That post argued that giving an agent a wallet is the easy part — the policy layer in front of the signature is the real product. This post is about the layer behind it.

Half the agent-payments stack lives after the signature

The popular framing of agent payments is the round trip: agent gets a 402, agent signs, server returns 200. Demos look great. Slides look great.

In production, the round trip is roughly a quarter of the work.

Once the signature is on the wire, you still need:

• A receipt — proof that the payment happened, that the customer can reconcile against a budget.
• A settlement decision — when does this hit the chain, who orchestrates it, what does it cost.
• An audit log that survives a six-month compliance review.
• Failure handling for the cases that always show up in week two: 5xx responses, double-charges, expired authorizations, network reorgs, channel disputes.

If you skip these, the agent runs but the operator can't sleep. This post is about how to think about each one.

What a receipt actually is

A receipt is the smallest data structure that lets a buyer's policy engine close the loop. It is not a UI element. It is a record format.

A useful receipt has, at minimum:

• request_id — the call this payment paid for
• amount and asset — exactly what was charged
• chain and network — where settlement happened (or will happen)
• recipient — who got paid
• signer — the agent's signing address, treated as the customer ID
• timestamp — when the authorization was signed
• status — pending, confirmed, voided, refunded
• settlement_ref — transaction hash, channel state hash, or facilitator-issued ID

That is the whole record. No PII, no human-readable display strings, no fluff. Agents and the systems behind them parse JSON; receipts are JSON.

Two design rules:

1. Receipts are addressable. GET /receipts/<id> returns the same record. Customers will fetch them later, sometimes much later, when their finance team asks.
2. Receipts outlive sessions. Keep them for years, not days. Compliance teams ask the wrong questions at the wrong time.

The agent's policy engine consumes receipts to decrement budgets, populate spend dashboards, and trigger alerts when something looks off. Without addressable receipts, every customer of yours has to maintain a parallel ledger by parsing your access logs. Don't make them do that.

Settlement: three options, three operating costs

Settlement is the act of finalizing a payment so it cannot be reversed. The choice you make here is mostly an operations question, not a protocol question.

Per-request settlement (x402-native)

Every paid call hits the chain. Simple, transparent, expensive at high volume because every call carries gas.

• Best for: low-volume APIs, occasional high-value calls, anything where the network cost is small relative to the call price.
• Watch out for: gas spikes, sequencer delays, reorgs on chains that have them.

Channel settlement (AMP)

The agent funds a channel, issues many off-chain headers, and the channel reconciles to chain on a timer or threshold.

• Best for: high-volume customers — agents that hit your endpoint hundreds or thousands of times per session.
• Watch out for: channel disputes, watchtowers, agent abandonment (the agent's process dies mid-session and the channel is left in an awkward state).

Treasury contract settlement

Both sides settle through an escrow contract that holds funds, releases them on agreed conditions, and emits a settlement event you can index.

• Best for: situations where neither party wants to fully trust the other or a facilitator. Common when the buyer is a large customer with their own finance ops.
• Watch out for: contract complexity, upgrade governance, deposit/withdrawal latency.

Most providers should start with per-request via a facilitator (so you don't run a chain integration day one) and add channel support when one customer's volume justifies it. Treasury contracts come last and only when you have a procurement-driven counterparty asking for them.

The audit log is for the customer's compliance team, not yours

When you ship agent-priced APIs, you take on a small but real obligation: the customer's compliance and finance teams are now reading your data.

Six months in, you will get an email. It will say something like "Can you give us the full payment history for signing address 0xabc… between Q3 dates X and Y, sorted by recipient and asset?" The team asking is not the developer who integrated you. They want a CSV.

Build for that conversation now, not later.

A useful audit surface is one boring HTTP endpoint:

• GET /usage?address=0x...&from=...&to=...
• Returns paginated receipts in the format above
• Stable schema, versioned, documented
• Available to the signing address itself, not gated behind another account system

Add CSV export later if asked. The shape rarely changes. The volume of requests is low. The presence or absence of this endpoint is what separates "we ship to enterprise customers" from "we ship to hobbyists who occasionally retry."

Failure handling: where production agent payments live or die

You can think about failure modes in three buckets.

1. The server failed

The customer's call returned a 5xx, but the payment may or may not have settled. Three rules:

• Auto-refund 5xx by default. Settle the payment and immediately refund. Mark the receipt voided with a reason code.
• Don't auto-refund 4xx. Bad input is the agent's problem. (Optional: discount it. Your call.)
• Be loud about partial failures. If a request was partially served — first byte sent before the connection dropped — say so explicitly in the receipt. Agents that retry blindly will double-charge themselves.

2. The settlement failed

The signature was valid, the call was served, but the chain transaction got dropped, replaced, or reorged.

• Reconcile asynchronously. Don't block the response on settlement.
• Update receipt status. pending → confirmed (or failed). Customers should poll receipts they care about until status is terminal.
• Have a dispute window. A short period (24 hours is reasonable) during which either side can flag a settlement issue. After that, it's final.

3. The agent abandoned the channel

For AMP-style channels, the agent process dies, the human comes back, the developer has to figure out what happened to $4.27 of unsigned channel state.

• Watchtowers help. Run them yourself or use a facilitator that does.
• Force-close timeouts must be reasonable. Don't lock funds for weeks because of a 2 a.m. process crash.
• Make channel state queryable. Same GET /channels/<id> shape as receipts. Same access pattern.

Operating proof: how we know this works

QBT Labs runs market making operations across four exchanges. Every order, every fill, every cancel is in some sense a paid API call against an exchange — there is metering, there are fees, there is reconciliation.

We hit the same operations problems agent-payments operators do. Receipts that don't match settlement events. Channel-state-equivalents that need reconciliation. Audit reports for prime brokers that look exactly like the audit reports a compliance team will ask you for.

That is the operating vertical that makes the AI Agent Payment Infrastructure we ship credible. Same primitives, run daily, against real money.

What to ship in the first month

If you are operating an agent-priced API today and the receipts/settlement/audit layer is light:

1. Define the receipt JSON. One file. Get it reviewed.
2. Make receipts addressable. GET /receipts/<id> returning the same record.
3. Make usage queryable. GET /usage?address=...&from=...&to=... with cursor-based pagination.
4. Pick one settlement path for now. Per-request via a facilitator is correct for almost everyone.
5. Document the dispute window. Even a single sentence in your terms is enough.

That is the operations foundation. Channels, treasury contracts, watchtowers, custom audit exports — all come later, driven by real customer asks.

Read the rest of the stack

This post is the operations layer. The complete picture is wider:

• Beyond the Wallet — the policy layer in front of the signature.
• How API Providers Can Monetize AI Agents — the commercial layer, with a provider checklist.
• x402 vs AMP vs MPP — the protocol choices that decide what your settlement layer looks like.
• AI Payment Glossary — definitions for every term in this post.

Building any of this and want to compare notes? QBT Labs ships the agent-payments infrastructure end to end and runs it daily against live markets. We're an email away.