Kaliski Autonomous Payment Infrastructure Framework

// When should you use the Kaliski Autonomous Payment Infrastructure Framework?

Use this skill whenever you are building a product, API, or agent workflow that involves AI agents spending money, purchasing API calls, or completing e-commerce checkouts on behalf of a human operator. Also applies when designing a merchant-side system that needs to safely accept payments from autonomous agents.

// What inputs do you need before designing an AI agent payment flow?

• Agent rolerequired
  Is the system acting as the agent/buyer side, the seller/merchant side, or both?
• Payment scoperequired
  What is the agent buying — API calls, physical/digital goods, SaaS subscriptions, or a mix?
• Spend policyrequired
  Maximum amount, currency, time window, and target seller(s) the agent is permitted to transact with.
• Payment methods in play
  Cards, crypto, bank transfer, or other methods the agent has access to.
• Existing API/checkout surface
  What programmatic interfaces (REST APIs, webhooks, MCP endpoints) the seller already exposes.

// What are the core principles of safe autonomous payment infrastructure?

// How do you apply the Kaliski payment framework step by step?

1. 1

   Classify every agent action as Discovery or Transactional

   Map out the agent's full task flow. Label each step: is it finding/recommending (non-deterministic OK) or credentialing/paying/checking out (must be deterministic)? Draw a hard boundary between the two zones. Nothing that crosses the boundary should rely on browser automation or parsed UI text.

2. 2

   Provision a Shared Payment Token for each intended transaction

   On the buyer/agent side, create a Shared Payment Token that wraps the underlying payment credential (card, wallet, etc.) and encodes: (a) maximum spend amount, (b) permitted currency, (c) expiry time window, (d) target seller scope. This token — not the raw credential — is what gets handed to the seller. The payment processor enforces the mandate; you do not rely on seller honesty.

3. 3

   Implement the Machine Payments Protocol (402 flow) for API/tool-call purchases

   If the agent is purchasing access to a tool or protected endpoint rather than a physical/digital product: the server returns HTTP 402 with an encoded payload describing what is being purchased, who the recipient is, and the payment mechanism. The agent reads this payload, approves payment using its Shared Payment Token or on-chain method, and retries the request. Never pass raw API keys for ephemeral tool interactions.

4. 4

   Expose a machine-readable product catalog on the seller side

   Replace or augment the human-facing storefront with a structured JSON catalog (products, descriptions, images, pricing). This eliminates the need for the agent to crawl, click, or parse HTML — it selects directly from structured data. This is the entry point to the Agent-to-Commerce Protocol (ACP).

5. 5

   Implement the Agent-to-Commerce Protocol (ACP) checkout loop

   The ACP defines a stateful, API-driven back-and-forth between agent and seller PSP. Each agent action (add item, change quantity, select shipping, apply payment method) triggers a seller response returning the full current cart state in structured form: line items, base prices, applicable tax, fulfillment options. The agent never infers cart state from a UI; it reads it from the structured response. Continue loop until agent confirms and payment is submitted via Shared Payment Token.

6. 6

   Relay cart state back to the human operator before final payment

   Because an agent acts as a proxy between buyer and seller, there is a risk of incorrectly relaying purchase details. Before executing final payment, surface the structured cart state (items, amounts, taxes, shipping) to the human operator for confirmation where the purchase value or complexity warrants it. This minimises disputes and chargebacks.

7. 7

   Audit the transaction trail

   Shared Payment Tokens are auditable by design — the payment processor logs each attempted charge, the mandate applied, and whether it was approved or rejected. Build logging into the agent workflow so every spend decision (including rejections due to mandate violation) is observable and attributable. This is the equivalent of a dashboard for the autonomous economy.

8. 8

   Design recurring or budget-based policies using token refresh flows

   For ongoing agent spend (e.g. weekly budgets, subscription-style access), model the credential lifecycle similarly to an OAuth access-and-refresh flow: the agent requests subsequent usage tokens as needed, each still scoped to a seller and amount. Do not issue an uncapped, long-lived credential — issue many tightly scoped short-lived ones.

// What are real-world examples of AI agents making payments safely?

// What mistakes should you avoid when building AI agent payment systems?

• Passing a raw card number or full payment credential to a seller — the seller can charge any amount; the mandate is unenforceable.
• Letting the agent operate a browser-based checkout form — form-filling and UI-clicking is slow, finicky, hard to observe, and produces non-deterministic outcomes in the transactional layer where determinism is required.
• Trusting the price the agent parsed from a webpage — prices drift, currencies differ, taxes are added; the only reliable price is the one returned in structured form by the ACP cart-state response.
• Issuing a single high-limit, long-lived credential instead of many tightly scoped short-lived Shared Payment Tokens — a compromised or misrouted token becomes a large blast radius.
• Hiding the agent's identity from the seller — sellers need card brand, last four, and credit type to run their existing risk analysis; suppressing this data breaks their fraud systems and reduces acceptance rates.
• Mixing discovery and transactional logic in the same non-deterministic loop — LLM-driven browsing is appropriate for finding products, never for executing payment.

// What are the key terms in the Kaliski Autonomous Payment Infrastructure Framework?

Shared Payment Token

A payment credential issued by the agent side that wraps an underlying payment method (card, wallet, etc.) and encodes a mandate — spend cap, permitted currency, time window, and target seller scope — enforced by the payment processor, not by the seller.

Machine Payments Protocol

A protocol (co-developed with Tempo) enabling HTTP-based tool calls to signal the need for payment by returning an HTTP 402 status code with an encoded payload describing what is being purchased, who the recipient is, and the payment mechanism; the agent resolves the 402 and retries.

Agent-to-Commerce Protocol (ACP)

A standard set of APIs and objects (co-developed with OpenAI) that define a stateful, structured back-and-forth between an agent, a seller, and their payment service provider — covering product catalog expression, cart creation, quantity updates, shipping selection, and checkout — replacing browser-based UI interaction with deterministic API calls.

Discovery vs. Determinism Separation

The architectural principle that the discovery/planning phase of an agent (finding products, making recommendations) can and should be non-deterministic, while the credentials/payments/checkout phase must be exclusively deterministic.

Blast Radius

The maximum financial or security damage possible if an agent transaction goes wrong — minimised by scoping every Shared Payment Token tightly to seller, amount, currency, and time.

Mandate

The encoded set of spend limitations (amount, currency, time, seller) attached to a Shared Payment Token, functioning like a smart contract enforced by the payment processor.

402 Flow

The Machine Payments Protocol interaction pattern: agent calls a protected endpoint, receives HTTP 402 with payment instructions, approves payment, retries request, receives the resource.

Robots Prefer Code

Kaliski's shorthand for the principle that agents should interact with seller systems via APIs and structured data (the right-hand side), not via dashboards or browser UIs built for humans (the left-hand side).

Agents as Economic Actors

The observation that AI agents are already spending money (tokens convert to dollars through LLM provider billing) and the design challenge is safely extending that spend to arbitrary third-party merchants.

// FREQUENTLY ASKED QUESTIONS