AI Agent Payment Receipts: Proving Approval and Delivery

An AI agent payment needs evidence of who participated, what was authorized, what happened to the money, and whether the purchased work arrived. Those answers may come from different systems. Your application needs to connect them to the same purchase.

“Payment successful” is an incomplete answer when the customer asks where their report is.

A payment processor can confirm a charge while the service is still generating the report. A signed receipt can establish who issued a statement without establishing that the report meets the order. And an agent can pay the correct merchant for something its operator never approved.

A purchase evidence record preserves enough information to distinguish those outcomes without relying on the agent’s account of what happened.

Keep four questions separate

Identity: Which buyer, agent, merchant, and payment recipient were involved? Record the authenticated parties and any verified relationships between them. A name entered in a request is a claim until the receiving system has a reason to accept it.

Authorization: Which approval, mandate, or account policy allowed this purchase? Check its limits against the actual transaction. Access to a wallet or API credential does not, by itself, establish permission for every purchase it can execute.

Payment: Was the payment authorized, captured, settled, rejected, or still pending? Preserve the provider’s actual status and its meaning. Different payment methods expose different stages.

Delivery: Was the order accepted, the service completed, or the purchased resource made available? Keep the merchant’s order or job reference and the evidence needed to check the promised result.

You may have strong evidence for one question and an unresolved answer for another. Your records should make that visible.

Connect approval to the exact purchase

Suppose an operator authorizes one data export from a particular provider for up to $20, with no subscription. The agent receives a $12 offer and proceeds.

The useful evidence includes the approved provider, export specification, price and currency, one-time purchase restriction, validity window, and the approval reference. Preserve the offer the execution system actually checked. Looking up today’s pricing page later cannot establish what was approved at the time.

In AP2, the checkout mandate authorizes checkout, while the payment mandate connects payment authority to the associated checkout. The current specification uses references and hashes to bind those objects. Participating verifiers still have to validate the signatures and constraints.

AP2’s security guidance explicitly considers manipulated agents and mismatched payment requests. Put enforcement in the trusted execution and payment components. A merchant page telling an agent to raise its budget is not a new approval.

For mandate types and their fields, use our AI agent payment mandate guide. Keep the permission attached to the purchase that used it.

Read the receipt’s actual claim

A receipt is evidence issued by a particular party about a particular event. Before relying on one, identify its issuer, the transaction it references, the status it reports, and how you can verify it.

MPP: an acknowledgment with a method-specific reference

The MPP receipt documentation describes a server acknowledgment of successful payment. Its Payment-Receipt header is optional, and the receipt includes a method-specific reference, such as a transaction hash or authorization reference.

That reference helps reconciliation. It does not make every payment method’s success state identical. The documented JSON encoding is not itself a digital signature, and a payment acknowledgment does not establish delivery of a separate job or order.

x402: settlement feedback and optional signed evidence

In x402 v2, PAYMENT-RESPONSE carries settlement feedback. Interpret it according to the configured scheme: the documentation includes schemes with different settlement timing.

x402 also documents a Signed Offers & Receipts extension. Check whether your integration supports and returns that evidence. Do not label every x402 response a signed receipt.

AP2: a verifier’s result tied to a mandate

AP2 defines checkout and payment receipts associated with its mandate flows. Preserve the relevant references and verifier result. Acceptance of payment authority, movement of funds, and fulfillment of the order remain questions your application must reconcile with the responsible systems.

Our x402, AP2, and MPP comparison covers protocol selection. This article’s question is narrower: what evidence did your chosen implementation produce, and what does it establish?

Build a private purchase evidence record

You do not need to invent another payment protocol. Keep references to the artifacts your existing systems produce, grouped under one internal purchase identifier.

• Parties: authenticated caller, internal agent and run identifiers, merchant account, payment recipient, and verified identity-mapping references.
• Approved terms: approval or mandate reference, policy version, offer or checkout reference, permitted amount and currency, and applicable limits.
• Execution: provider request reference, selected payment method or scheme, and the operation identifier used by the integration.
• Payment evidence: provider status, receipt or transaction reference, issuer, verification result, and time checked.
• Delivery evidence: order or job reference, fulfillment status, result location where appropriate, and unresolved discrepancies.

These are suggested internal record groups, not AP2 fields or a Headless Domains API schema. An identifier is useful only if it leads to evidence your team can retrieve and evaluate.

Keep this record access-controlled. Store credential references rather than reusable payment credentials, bearer tokens, private keys, or raw card details. Minimize customer data and restrict who can alter the evidence. A log the agent can freely rewrite is a weak basis for reviewing that agent.

A paid export that never finished

Return to the $12 export. Imagine the payment provider confirms the charge and the merchant returns a job identifier. The job later fails.

The accurate outcome is: payment confirmed, delivery failed. Calling the whole purchase “successful” hides the customer’s problem. Calling it “failed” without preserving the payment evidence risks paying again.

The record should connect the original approval, the merchant’s offer, the payment reference, and the failed job. That gives support enough context to investigate fulfillment or the applicable refund process.

A refund needs its own evidence, too. A refund request is not a completed refund. Retain the original purchase and append the later status rather than replacing its history.

If the response disappears and the outcome is unknown, follow the provider’s reconciliation and retry contract. Our agent retry and idempotency guide covers that decision. A correlation identifier alone does not prevent a second charge.

Where a Headless Domains identity belongs

A public name gives people and compatible agents a maintained reference for the service. Its records can point to the operator’s published information, official service endpoints, machine-readable manifests, and supporting documentation.

Use that name alongside the private purchase record when it helps identify the same service across systems. Preserve the identity information and verified mapping relied on at execution time. A profile can change after a transaction; its current contents are not a historical record.

The Headless Domains manifest reference describes the public information agents can inspect. Connecting a name to an authenticated caller, merchant account, or signing key still requires verification by the relying system.

Payment systems already have identity mechanisms. For example, mppx supports configured Web Bot Auth and Trusted Agent Protocol attestations on initial requests and paid retries. A Headless Domains name can complement those mechanisms; it is not a requirement for MPP, x402, or AP2.

Publish the service information others need to discover and inspect. Keep buyer approvals, private receipts, credentials, and transaction history in the systems responsible for them. Registering a name does not automatically verify a payee, enforce a spending limit, or connect another provider’s logs.

Can someone reconcile the purchase without the chat?

Before enabling autonomous spending, review an existing sandbox transaction with someone who did not run it. Give them the purchase identifier and access to the relevant records.

Can they establish who approved the purchase, which offer was accepted, which party received payment, what status the payment provider reports, and whether the merchant delivered?

Record any answer that remains unknown. You have found a concrete integration gap, whether it is a missing approval reference, ambiguous provider status, or an order that cannot be connected to its payment.

For general caller tracing, see our API call attribution guide. For the public service identity, start with the Headless Domains skill file and ask your agent to explain the registration options before taking action. Give the service a name people can recognize, then keep the evidence needed to account for each purchase.