Receipts and evidence for agentic payments

Evidence model

Build a receipt for explanation, not decoration

Receipts for agentic payments must connect adaptive decision-making to a deterministic financial outcome. The principal needs to recognize the seller, items or resource, total, currency, payment status, fulfillment, and recourse. Operators need the agent, mandate, policy version, credential reference, request digest, rail identifiers, and verification history. Finance needs settlement and reconciliation references. Security needs the identity and signature trail. A single audience should not force every other audience to work from an incomplete record.

The receipt should distinguish evidence from interpretation. A merchant order response can establish what the seller recorded. A processor or facilitator status can establish its reported rail state. A cryptographic signature can establish integrity and key possession under defined assumptions. The agent's narrative can summarize why it chose an option, but it cannot independently prove authorization or fulfillment. Label evidence by issuer and verification method so later reviewers know which claims are authoritative.

A transaction hash proves neither user intent nor merchant fulfillment. It is one evidence reference in a larger commercial record.

Join the minimum complete evidence set

A receipt record should have its own stable identifier and references to the principal, agent, intent, mandate, order, policy decision, credential, payment, fulfillment, and recourse case. Record values with explicit units: amount, currency or asset, network, fees, quantity, and timestamps with time zone. Store both current status and the append-only events that produced it. A mutable summary makes the interface convenient; the event history makes the conclusion reproducible.

The order snapshot deserves special care because it bridges authorization and fulfillment. Preserve merchant identity, line items or requested resource, price, fees, tax where applicable, cancellation or refund terms, delivery promise, and a canonical digest. If the merchant changes terms after approval, retain both versions and stop execution or request step-up according to policy. Overwriting the approved cart with the final cart destroys evidence of the difference the system needed to control.

Preserve provenance and verification results

Cryptographic evidence is only as useful as its verification context. Store the signature or durable reference, canonical payload digest, algorithm, key identifier, issuer, verification time, and result. Preserve the protocol and schema version used to parse the payload. HTTP Message Signatures provide a standardized way to protect selected request components, while AP2 explores signed mandate artifacts. Neither removes the need to know which components were covered, whether the key was trusted, and whether freshness and replay rules passed.

Evidence can arrive after the initial response. Webhooks, settlement confirmations, fulfillment events, and refund updates should append to the receipt history with issuer and delivery metadata. If a later verification corrects an earlier assumption, record a correcting event rather than rewriting history. Tamper evidence does not require putting private transaction data on a public ledger; append-only storage, access controls, signed records, and independent digests can provide strong operational assurance without exposing the principal's purchases.

• Store canonical digests and verification metadata, not only a `signature_valid` boolean.
• Record which headers, fields, or payload bytes a signature actually covered.
• Keep protocol parsing versions so old evidence remains reproducible after schema changes.
• Authenticate evidence updates and deduplicate repeated delivery events.
• Represent corrections as linked events with reason and reviewer instead of deleting prior state.

Make receipts useful without turning them into data leaks

Receipts combine identity, behavioral, commercial, and financial information, which makes them attractive and sensitive. Apply least-privilege views: a user-facing receipt should not expose internal risk rules, raw credentials, private keys, full payment account data, or unnecessary agent prompts. Support may need commerce and status details, finance may need settlement references, and security may need verification metadata. Those needs do not justify one unrestricted record copied into every analytics system.

Retention should follow purpose and obligation. Keep evidence needed for accounting, disputes, security review, and regulatory duties, but avoid retaining raw model context or personal data merely because storage is easy. Tokenize sensitive identifiers, encrypt protected fields, audit access and exports, and define how corrections or deletion requests interact with immutable financial records. PCI DSS requirements apply where cardholder data enters scope; stablecoin or bank flows still require an explicit privacy and access model.

• Create separate user, support, finance, and security projections over the same evidence graph.
• Redact secrets at ingestion so they cannot leak through logs, receipts, or support exports.
• Expose verification status and issuer without publishing private mandate contents.
• Document retention by field family and legal or operational purpose.
• Test that authorization changes remove access to receipt details and exported artifacts.