Skip to content
Back to blog
Agentic Commerce6 min read

Trust Receipts: Signed Context for Agentic Commerce

A TrustReceipt preserves signed context for a covered action. It does not by itself prove buyer intent, payment settlement or that the event occurred.

Executive summary

A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.

Published

2026-06-26

Updated: 2026-09-13

6 min read

Author

Trusteed

Published by Trusteed

Written and maintained by the team that builds Trusteed. Technical claims in these articles are backed by the surfaces linked from each piece and by the signed capability registry at /.well-known/trusteed-capabilities.json, which is the arbiter when an article and a status surface disagree.

About Trusteed

Category

Agentic Commerce

agentic-commerceAI AgentsCommerce OpsBuyer JourneyFuture CommerceProtocols
Illustration of an agent checkout and receipt verification; a receipt alone does not prove payment.
Illustration of an agent checkout and receipt verification; a receipt alone does not prove payment.

A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.

Issuing a receipt does not mean a payment was settled. At the 2026-09-13 review, the public merchant registry reported beta_closed, no production merchants and accepts_real_payments=false. Check /.well-known/merchant-index.json for current availability; demonstrations and checkout previews are not evidence of real purchases.

Essential insight

What a TrustReceipt records

A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.

  • 1
    The action and context available to Trusteed on a covered path.
  • 2
    The recorded policy decision and authorization context, when captured; not independent proof of buyer intent.
  • 3
    References and canonical hashes of input/output when present; not a guarantee that every underlying record is embedded.
  • 4
    A signature that makes changes to the signed record detectable. Payment references, when present, still require external evidence of settlement.

Why a dispute still needs other evidence

An agent’s declared intent, a merchant’s policy decision and a payment provider’s outcome can live in different systems. A TrustReceipt helps identify what Trusteed recorded and whether the signed content changed. It does not replace buyer consent, payment-provider records, order fulfillment evidence or a legal assessment.

From a covered action to a signed record

  • 1
    An agent invokes an operation on a path with receipt issuance enabled.
  • 2
    The applicable controls evaluate the request; recorded identity context depends on that path’s verification policy.
  • 3
    Trusteed captures the available context, decision and references. A settled payment is not a prerequisite for every receipt.
  • 4
    The issuance path signs and persists the record. Check the individual result; do not infer successful issuance from configuration alone.
  • 5
    Where chaining is present, validate the chain reference separately. Corpus-wide chaining is not claimed.

Hash chaining and checkpoints are armed, not measured across the corpus. Receipts issued before the 2026-08-06 genesis are not chained, and post-genesis coverage has not been established. A valid individual signature does not prove that no record is missing from a sequence.

Verify v1.0 and distinguish v1.1

For v1.0, obtain the issuer's trusted public key from its JWKS and retain the verification material. Verify the JWS with the key selected by kid. Compare canonical input/output hashes only when the original data is available. Historical embedded JWKS and additional time evidence belong to v1.1 hardening, which remains gated; they are not guaranteed by a v1.0 receipt.

The public health endpoint reports issuance activity and the latest schema version. At this review it reported v1.0 issuance; that is a service observation, not independent validation of every receipt. v1.1 hardening remains behind a feature flag. Qualified timestamping is not active, and legal claims remain subject to external review.

What merchants can use it for

  • 1
    Preserve signed evidence of the authorization context available at the time.
  • 2
    Detect changes to signed records during an investigation.
  • 3
    Link a recorded decision to external order or payment evidence where references exist.
  • 4
    Share a verifiable record and the required verification material with an authorized reviewer.

Portability has prerequisites

Retain the signed record, the trusted public key and any original data needed to reproduce its hashes. Portability does not recover lost records or automatically provide historical key material. v1.1 historical snapshots must not be assumed in v1.0. Keep the source evidence under the applicable access and retention rules.

A TrustReceipt preserves signed context for a covered action. It does not by itself prove buyer intent, payment settlement or that the event occurred.

Essential insight

Frequently asked questions

What does a TrustReceipt prove?

A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.

Does every receipt confirm a payment?

Issuing a receipt does not mean a payment was settled. At the 2026-09-13 review, the public merchant registry reported beta_closed, no production merchants and accepts_real_payments=false. Check /.well-known/merchant-index.json for current availability; demonstrations and checkout previews are not evidence of real purchases.

Can every receipt be verified offline?

For v1.0, obtain the issuer's trusted public key from its JWKS and retain the verification material. Verify the JWS with the key selected by kid. Compare canonical input/output hashes only when the original data is available. Historical embedded JWKS and additional time evidence belong to v1.1 hardening, which remains gated; they are not guaranteed by a v1.0 receipt.

Is every receipt hash-chained?

No. Chaining is armed, but corpus-wide coverage is not measured. Check the individual receipt and chain evidence; a valid signature alone does not prove a complete sequence.

Sources and references

Related articles

Trust Receipts: Signed Context for Agentic Commerce | Trusteed | Trusteed