Building safe Payment Infrastructure for the autonomous economy — Steve Kaliski, Stripe
Summary
Steve Kaliski, a principal software engineer at Stripe who previously led Stripe's Issuing team, presents the infrastructure challenges and solutions Stripe has developed to enable autonomous agents to transact safely with businesses. The core thesis is a clean architectural separation: discovery and exploration should embrace non-determinism (LLMs excel here), while credentials, payments, and checkout require strict determinism to be safe.
Kaliski frames agents as already being economic actors — every token processed via Claude Code, Codex, or similar tools represents money spent with the LLM provider. The question Stripe is tackling is how to extend that spend to arbitrary merchants. The four categories of risk he identifies are: buying from the wrong place (phishing/fake domains), buying the wrong thing, spending the wrong amount (due to currency drift, tax miscalculations, or parsing errors), and using the wrong credential.
The first solution is Shared Payment Tokens. Rather than passing raw card numbers to sellers, an agent's Stripe account provisions a token that encodes a spend mandate — scoped to a specific seller, capped at a specific amount (e.g., $25), and time-limited (e.g., 30 days). A live demo shows the token being created with a $25 cap, the seller attempting to charge $50 and being declined by Stripe, and then succeeding at $25. Critically, the token still surfaces card brand and last-four digits so sellers can run their existing risk systems without any changes. The token works across hundreds of payment method types beyond credit cards.
The second solution is the Machine Payments Protocol, built in collaboration with Tempo. The protocol repurposes the HTTP 402 status code ("Payment Required") so that API endpoints can signal a cost, identify the recipient, and specify the payment mechanism. A live demo shows a curl request to a protected endpoint returning a 402 with a structured payload indicating a one-cent cost payable in USD on the Tempo blockchain, after which payment is approved and the transaction lands on-chain. This is designed for ephemeral, per-call tool payments where long-lived API keys are impractical.
The third solution is the Agent-to-Commerce Protocol (ACP), developed with OpenAI. ACP is a standard set of APIs and JSON objects for expressing product catalogs and conducting stateful checkout negotiations between agents and sellers. Instead of an agent crawling a website to find products and fill forms, the seller exposes a structured product catalog and the agent initiates a programmatic back-and-forth — updating cart quantities, selecting shipping options, applying payment methods — with the seller returning structured cart state at each step. A live demo uses Stripe Press (Stripe's book store) to show an agent asking for AI book recommendations, receiving a JSON product catalog, initiating a checkout, and completing payment via a shared payment token. The seller retains full control of the transaction and receives the risk signals they need.
Kaliski closes by noting that Stripe Projects is built on these shared payment token primitives, and briefly addresses recurring budget use cases (analogous to OAuth access/refresh token flows). For businesses, the practical implication is clear: web UIs increase the likelihood of non-deterministic, error-prone agent interactions; exposing APIs and agent-friendly endpoints enables the deterministic flows that minimize transaction risk. The recommended architecture is a non-deterministic planner (LLM) operating within deterministic constraints, with verifiable parties and structured negotiation, to achieve a minimal blast radius for autonomous spend.
Key Takeaways
- •Separate discovery (non-deterministic, LLM-driven) from transactions (deterministic, API-driven) — this is the foundational design principle for safe autonomous payments.
- •Never pass raw card numbers to agents or sellers; use shared payment tokens that encode spend limits, seller scope, currency, and time constraints enforced by Stripe.
- •The HTTP 402 status code can be repurposed so any API endpoint signals its payment requirement inline with the request, enabling per-call micropayments without long-lived credentials.
- •Implement the Agent-to-Commerce Protocol (ACP) to expose a machine-readable product catalog and stateful checkout API so agents don't have to scrape your web UI.
- •Shared payment tokens still surface card brand and last-four digits to sellers, preserving their existing risk and fraud systems without requiring any changes.
- •Recurring agent budgets can be modeled similarly to OAuth access/refresh token flows — scoped credentials that can request subsequent usage.
- •Building only web UIs increases non-deterministic agent interactions and transaction errors; agent-friendly APIs minimize disputes, chargebacks, and accidental overspend.
- •Stripe Projects is built on shared payment token primitives — this is production infrastructure, not experimental.
- •The ACP protocol supports flexible payment methods including crypto (Tempo blockchain), cards, and hundreds of other payment types within the same checkout flow.
Transcript
Just want to thank everyone for being here. Um, I'm from Stripe and today I'm going to talk about building safe payment infrastructure for the autonomous economy or how we can let robots spend money and how businesses can receive money from robots. So just about me, I'm a principal software engineer at Stripe. Spent my first four years leading our issuing team, so that's our product that lets developers create physical and virtual credit cards that historically would be for humans and increasing...
Related Sessions
