What Is a Verifiable Payment Receipt for an AI Agent?

Definition

A verifiable AI agent payment receipt is a cryptographically checkable record that a proposed payment action satisfied defined policy rules before execution. The complete receipt binds the policy evaluation to the proposed action and governing policy version. Acceptance also requires checks for freshness, record association, replay, accepted verification parameters, and links to authorization and settlement records.

The receipt provides evidence only for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of external inputs, approval, execution, or settlement.

Defining a verifiable AI agent payment receipt

A verifiable AI agent payment receipt is a structured evidence record that lets an independent verifier check a defined pre-execution claim. The claim states that a proposed covered payment action was evaluated against a specified policy version. The receipt cryptographically binds that evaluation to the proposed action and governing policy version.

The term covers three separate layers. A cryptographic proof demonstrates correct evaluation of a defined statement. A complete receipt combines that proof with claims identifying the proposed action, policy version, and relevant record commitments. The public verification context defines the accepted verification parameters and statement schema. It also defines the freshness window, replay rules, and record associations needed to accept the receipt.

A conventional payment receipt serves a different purpose. Commercial receipts usually document an exchange after payment. They can record the parties, amount, goods or services, and tax treatment. Bank transfer confirmations similarly record transaction details and support traceability after authorization or settlement. Conventional payment receipts therefore provide retrospective financial evidence rather than evidence of pre-execution policy evaluation.

An approval message also serves a narrower purpose. A signed approval can identify an approving party and bind that approval to specified data. It does not establish that formalized policy rules were evaluated correctly unless its verification statement expressly covers that evaluation.

A verifiable receipt supplies policy-evaluation evidence within a larger payment record. It does not by itself prove user consent, payment authorization, execution, or settlement. Separate evidence must connect the receipt to the payment authorization and application record. Payment-rail evidence must connect those records to the resulting settlement state.

The cryptographic proof, the complete receipt, and the verification context

A verifiable AI agent payment receipt has three distinct layers. The cryptographic proof supports a defined mathematical statement. The complete receipt connects that proof to a specific proposed payment action and governing policy version. The verification context defines how a relying party must interpret and check the receipt.

The cryptographic proof is a compact mathematical artifact. For Groth16, verification requires the proof, the expected public inputs, and the correct verification key. Sui documents these as separate verification inputs (opens in a new tab). The proof shows that a valid private witness satisfies the relation encoded by the key for those public inputs. The proof can do so without disclosing the protected inputs used to generate it.

Proof bytes cannot identify the relevant business claim by themselves. They do not specify which proposed payment was evaluated. They also do not identify the governing policy version or explain how encoded values map to payment fields. A compressed Groth16 proof represented in a 128-byte format is therefore a cryptographic artifact. It is not a self-contained receipt.

The complete receipt contains or references the proof and its public statement. The public statement can include an action commitment and a policy identifier or version. It can also include an evaluation result, a time value, and a record identifier. These fields bind the mathematical claim to a payment record that another party can inspect. Total receipt size depends on the public inputs, identifiers, encoding, and referenced verification material.

The verification context defines how the verifier interprets the receipt and which parameters it accepts. It identifies the algorithm, verification key, and parameter set. It also defines the public-input schema and semantic conventions. A portable receipt can package some elements and reference others through stable identifiers. The verifier must authenticate those references rather than accept parameters supplied without validation.

The verification key identifies the relation being proved. The public-input schema explains what each encoded value represents. zkVerify likewise treats the proof, verification key, and public inputs as distinct objects (opens in a new tab). An attacker-selected key or mismatched schema could make a valid proof irrelevant to the payment under review.

Cryptographic validity establishes only that the proof satisfies the defined mathematical relation for the supplied public inputs and accepted verification key. Receipt acceptance also requires binding the receipt to the expected action and governing policy version. The verifier must check freshness and record association. It must also enforce the applicable replay rules. The verifier must also confirm accepted verification parameters and connect any settlement claim to separate payment-rail evidence. A valid proof does not establish settlement by itself.

What a receipt can establish

A valid receipt can establish that covered policy rules were evaluated correctly for the statement defined by its public inputs. Verification checks the proof against those inputs and an accepted verification key. The public inputs identify the claimed result and any exposed policy reference. The accepted verification key identifies the mathematical relation used to evaluate that claim. Sui’s Groth16 documentation (opens in a new tab) treats the proof, public inputs, and verification key as separate requirements.

The receipt can bind that evaluation to a commitment representing the proposed action. A verifier can compare the bound commitment with the expected payment action. A mismatch indicates that the receipt applies to a different proposal.

The receipt can also bind the result to a governing policy identifier and version. Version binding prevents a valid evaluation under one policy from being presented as evidence under another policy.

Policy-evaluation evidence forms one link in the payment evidence chain. It does not replace evidence of delegation, payment authorization, execution, or settlement. Intent evidence covers delegated authority. Native payment authorization covers permission to move funds. Execution and settlement records cover later events. AP2 (opens in a new tab) represents authorization and payment claims through distinct mandate and receipt objects.

Shared identifiers or cryptographic commitments must connect the receipt to the other records. Without that association, a verifier cannot conclude that the evaluated policy governed the payment that executed or settled. The receipt supports its defined statement for covered actions. It does not establish broader agent conduct beyond that statement.

Evidence layers in an agent payment

An agent payment can produce several evidence objects. Each object supports a distinct claim within the payment chain.

Inherence operates at the policy-evaluation layer. Its receipts provide independently verifiable, privacy-preserving evidence for covered pre-execution checks.

These claims are linked rather than interchangeable. A shared payment identifier or cryptographic commitment should connect the mandate and proposed action to the policy receipt. Corresponding references should connect the payment authorization, execution record, and settlement record. Missing links prevent a verifier from concluding that the evaluated policy governed the payment that executed and settled.

Acceptance checks a verifier must perform

A verifier must treat receipt acceptance as a fail-closed procedure. The verifier must reject the receipt when any required check fails.

• Parse the receipt. The verifier must reject malformed encoding, missing required fields, unsupported schemas, and invalid field types before performing cryptographic work.
• Select accepted verification parameters. The verifier must pin or authenticate the permitted algorithm, parameter set, and verification key. It must not trust parameters supplied only by the receipt. Groth16 verification (opens in a new tab) requires the proof, public inputs, and correct verification key as separate inputs.
• Verify the cryptographic artifact. The verifier must validate the proof or signature against the selected key and public inputs. Proof validity establishes only the defined cryptographic statement.
• Check expected-action binding. The verifier must compare the receipt’s action commitment with the payment action under review. Relevant fields can include the payee and amount. They can also include the currency, payment instrument, and checkout reference. AP2 (opens in a new tab) binds payment authorization to mandate data associated with a checkout. Its verification procedure also requires evaluation of disclosed constraints.
• Check policy binding. The verifier must confirm that the receipt identifies the expected policy and governing version. A valid proof for another policy version cannot authorize the current action.
• Enforce freshness. The verifier must reject receipts outside the accepted issuance or execution window. For example, the PEAC verification procedure (opens in a new tab) applies a five-minute issuance-time window.
• Associate the correct record. The verifier must match record identifiers, transaction identifiers, or hash references with the business record under review. AP2 dispute checks likewise require independent recomputation and comparison of receipt references.
• Prevent replay. The verifier must track nonces, unique transaction identifiers, or previously consumed receipts. A fresh and cryptographically valid receipt can still be unacceptable if another request already used it.
• Link authorization to settlement evidence. When acceptance depends on completed payment, the verifier must match the receipt to the relevant payment identifier and PSP or network confirmation. A receipt reference alone does not establish settlement. The payment rail must confirm settlement independently.

The verifier must complete every applicable check before accepting the receipt. Failure of any required check must cause rejection.

What verification does not establish

Verification confirms a defined statement. It does not confirm every fact associated with a payment. A valid proof establishes that the defined mathematical relation holds for the supplied public inputs under the accepted verification key.

A proof cannot independently determine whether external inputs reflect reality. False or inaccurate source data can still produce a valid proof. The cryptographic check confirms the defined relation over the supplied inputs rather than the truth of the underlying real-world claims.

An issuer remains the root of truth for an external claim. For example, a proof can confirm that a signed credential satisfies a policy condition. The credential issuer remains responsible for the underlying claim. Zero-knowledge techniques can prove that credential data satisfies a defined statement without disclosing the protected data. They do not independently validate the issuer's underlying claim.

Receipt verification does not grant approval by itself. User consent, payment authorization, and other required approvals need their own evidence and validation. Receipt verification also does not prove settlement. The verifier must reconcile the payment rail’s settlement record under its applicable finality rules.

Zero-knowledge and zero-trust describe different concepts. Zero-knowledge protects encoded inputs while proving a defined statement. Zero-trust governs how systems authenticate and authorize access. A zero-knowledge receipt reduces and relocates trust. A verifier still relies on defined parties and artifacts, including input issuers, policy commitments, and accepted verification parameters. It does not remove trust.

Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path.

AP2 and x402 in context

AP2 already defines authorization checks that a separate policy receipt should not replace. The AP2 specification (opens in a new tab) uses cryptographically protected Checkout Mandates and Payment Mandates to connect user authority with a specific payment. AP2 verifiers process the mandate chain and verify signatures. They also confirm key binding and supported schema versions. Additional checks cover transaction references and freshness. Verifiers evaluate every disclosed constraint and reject unknown constraints.

AP2 also defines signed Mandate Receipts and Payment Receipts. A Mandate Receipt records a verifier’s acceptance or rejection and references the received mandate by hash. A Payment Receipt adds payment status and a payment identifier. Successful Payment Receipts may include confirmation identifiers from a payment service provider or network. These records preserve authorization and payment evidence without proving a separate external policy computation.

x402 separates payment verification, protected resource execution, and settlement. Its /verify operation (opens in a new tab) checks a PaymentPayload without committing payment state. Its /settle operation commits state and returns transaction information. The exact scheme (opens in a new tab) requires the recipient and amount to match the payment requirements. Its verification and settlement procedures also define replay and settlement checks. The upto scheme (opens in a new tab) authorizes a maximum amount and limits settlement to the actual charge within that ceiling.

A policy receipt can complement these native controls. Such a receipt could provide evidence that a covered payment action passed formalized policy evaluation before signing or submission. The receipt must bind to the same logical payment through its requirements, payload, mandate, transaction reference, or another accepted identifier. AP2 mandate verification and x402 settlement checks would remain separate acceptance requirements. Any connection between these objects describes an architectural pattern unless a specific integration has been demonstrated.

Where Inherence fits

Inherence (opens in a new tab) provides pre-execution policy enforcement and independently verifiable evidence for covered AI agent payment actions. Inherence evaluates each proposed covered action against the mandate’s formalized policy rules before execution. When an action falls outside those rules, Inherence blocks it before it reaches the defined execution path.

For a covered action that passes, Inherence produces a policy receipt with privacy-preserving cryptographic evidence. The evidence establishes that the covered rules were evaluated correctly for the action and policy version named in the receipt’s defined statement. An independent verifier can check that claim without receiving the protected inputs used to generate the proof.

Monitoring tools record activity for later review. Inherence evaluates covered actions before execution and produces evidence of that evaluation. The surrounding payment system remains responsible for payment authorization, execution, settlement, and their associated records.

Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input. It does not cover actions executed outside that path.

FAQ

Is a verifiable AI agent payment receipt proof that payment occurred?

No. A valid policy receipt can show that a covered proposed payment passed defined policy rules. Payment authorization, execution, and settlement require separate evidence. Payment protocols may record settlement through network transaction identifiers or provider confirmations, but a verifier must reconcile those records under the payment rail’s rules.

What happens if the governing policy version changes?

The receipt remains bound to the policy identifier and version used during evaluation. A verifier must compare that version with the expected policy for the proposed action. Historical receipts also require the accepted verification key, public inputs, and schema for that policy version. A later policy update does not retroactively change an earlier receipt.

Can a verifiable payment receipt be replayed?

A copied receipt can be presented again unless the verifier applies replay controls. The verifier should check the receipt's freshness and action binding. It should also validate any timestamp, nonce, or unique receipt identifier required by the accepted replay policy. The verifier should also record prior acceptance where repeated use could authorize duplicate execution. The PEAC specification (opens in a new tab) recommends nonce tracking or timestamp windows for replay resistance.

Does a receipt prove that the agent remained inside its mandate?

No. A receipt can establish that a covered action was evaluated against a specified policy statement. It does not establish the agent’s broader intent or every instruction outside that statement. It also does not independently establish the truth of external inputs. Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path.

Conclusion

A verifiable AI agent payment receipt provides bounded evidence about a defined pre-execution policy evaluation. It establishes a defined claim about a covered policy evaluation. It does not establish every fact about the payment.

Buyers should examine which proposed action and policy version the receipt binds. They should confirm that an independent party can verify the claim without relying on the issuing vendor. They should also determine how the payment infrastructure handles freshness, replay prevention, record association, and settlement linkage.