Agent Commerce

Verifiable agent transactions

Every AI agent spend request is governed by policy, executed on a payment rail, and issued as an Ed25519-signed receipt that any third party can verify — without trusting the platform that processed it.

What this actually means

Traditional payment systems answer one question: did money move? For human-initiated payments, that is usually enough.

For AI agents, it is not. When an autonomous system spends money, you also need to know:

• —What was authorized before execution began?
• —What exactly occurred during the transaction?
• —What policy governed the decision at that moment?
• —Can another system verify this independently — without trusting you?

Verifiable agent transactions answer all four. Instead of treating a payment as an isolated event, the system produces a structured, inspectable lifecycle — from authorization through execution through signed receipt.

This turns payments into verifiable events: something systems can trust, reason about, and build on.

Machine-readable summary (for agents and systems)

{
  "term": "Verifiable agent transactions",
  "slug": "verifiable-agent-transactions",
  "category": "agent-commerce",
  "type": "payments-architecture",
  "short_definition": "A payments architecture in which every AI agent spend request is policy-governed, executed through a documented rail, and produces a cryptographically signed receipt independently verifiable by any third party.",
  "definition": "Verifiable agent transactions are a payments architecture in which every spend request by an autonomous AI agent is governed by policy, executed through a documented rail, and produces a cryptographically signed receipt that any third party can verify independently — without trusting the platform that processed the payment.",
  "canonical_url": "https://certifieddata.io/agent-commerce/verifiable-agent-transactions",
  "concept_graph": {
    "parent": null,
    "children": [
      "Agent Commerce receipt",
      "Payment authorization",
      "Payment verification",
      "AI spend governance",
      "Payment policy engine"
    ]
  },
  "rails": [
    "stripe",
    "usdc_base",
    "usdc_ethereum",
    "eth_ethereum"
  ],
  "proof_surfaces": [
    "GET /api/payments/verify/:receiptId",
    "GET /.well-known/certifieddata.json"
  ],
  "related_terms": [
    "Agent Commerce receipt",
    "Payment authorization",
    "Payment verification",
    "AI spend governance"
  ]
}

What the system provides

Six core primitives, each with a distinct role.

Payment lifecycle

Every payment follows the same sequence. Each step produces a record.

1. 1

   Agent requests spend

   Agent submits a spend request with amount, merchant, rail, purpose, and idempotency key.

2. 2

   Policy evaluates

   The payment policy engine checks rail, currency, merchant, spend limit, and purpose tags. Returns authorized, blocked, or needs_review.

3. 3

   Execution dispatched

   Authorized requests are dispatched to the payment rail. Stripe is the active Phase 1 rail; USDC and ETH rails are interface-ready.

4. 4

   Decision record written

   The authorization decision is written as a decision lineage entry: actor, decision label, policy version, and reason codes.

5. 5

   Signed receipt issued

   A payment receipt is issued: Ed25519-signed over an RFC 8785-canonicalized payload. Receipt hash is stored and verifiable.

6. 6

   Independently verifiable

   Any party with the receipt ID can verify hash integrity and signature against the published public key — no CertifiedData account required.

Core concepts

Each concept has a distinct, non-overlapping role in the system.

Explore the system

Tools, infrastructure, and developer surfaces.

FAQ