My DevWorld 2026 recap covered the headlines of Stripe’s keynote, “Teaching agents to pay”, by Allison Farris, Developer Advocate at Stripe (name and title as shown on her opening slide). This post goes through the engineering half of the same session, the part that showed how a checkout agent is actually put together. The demo used Stripe’s own components and a Universal Commerce Protocol slide.
What UCP is
The slide described the Universal Commerce Protocol (UCP) as “the shared language that lets agents and merchants transact instantly”, with Stripe, Shopify, Google, Amazon, Target, Wayfair, Salesforce, Microsoft, Meta and Etsy listed as tech council members.
The UCP slide: “the shared language that lets agents and merchants transact instantly”.
I checked this against the project’s own site. ucp.dev describes UCP as an open standard with building blocks for agentic commerce, from discovery to checkout, so that platforms, agents and businesses interoperate through one protocol without custom integrations. It covers catalog search, cart, checkout, identity linking and order tracking, builds on REST and JSON-RPC and works with the Agent Payments Protocol (AP2), Agent2Agent (A2A) and Model Context Protocol (MCP). The specification and the GitHub repository are public under Apache 2.0. A follow-up slide showed the basic shape: an AI agent sends a request through UCP to a merchant and gets a response.
The agent loop
Before UCP came into the demo, the session built the agent from scratch. The first code slide was “The Loop”: a while (iterations < MAX_ITERATIONS) block that calls the model, runs any tool calls and adds the results to the conversation, and breaks when the model returns text.
“The Loop”: call the model, execute tool calls, stop when it answers in text.
The iteration cap is the guardrail worth copying. An agent that can spend money should have a hard bound on how many steps it takes.
Commerce tools and checkout state
The next slide, “Commerce Tools”, showed three steps. The LLM decides on a tool, for example create_checkout. The backend executes it. The result is returned to the LLM as a tool message, here with a checkout id, a status of not_ready_for_payment and a total.
Commerce tools: the model picks the tool, the backend executes it, the status goes back to the model.
A later slide, “An AI agent is ready to buy”, walked through the conversation: the agent adds the item to the cart, asks the user for a shipping address, and passes it to the backend. Following slides showed the checkout status moving to ready_for_payment, with the model then requesting a payment method.
The chat asks for a shipping address, and the agent backend turns that into the next tool call.
My take: the useful design idea is that the backend owns checkout state and the model only reads it. The model never decides that a checkout is paid, it reads a status the server produced.
Shared payment tokens
For payment, a slide on the Shared Payment Token (SPT) showed a buyer, an AI agent and two merchants. The agent issues an SPT through Stripe and shares it with each merchant. According to the slide, a shared payment token from the agent’s account is used to generate a PaymentIntent in the seller’s account, which lets users shop across multiple sellers.
Shared Payment Token: the agent’s token is used to create a PaymentIntent on the seller’s side.
The same session also covered Stripe’s Machine Payment Protocol with Tempo, as covered in my earlier recap.
Persona engineering
One slide, “Persona engineering for developers”, put the policy in the system prompt: “The prompt IS the ethics policy, written in plain English.” The example rules were to always disclose that it is an AI, never pressure customers to buy, say “I don’t know” when unsure, and respect “no” instead of pushing back. A follow-up showed the opposite, a pushy persona, as the test-mode counter-example.
A system prompt as ethics policy: disclose the AI, no pressure, respect “no”.
My take: a prompt is a good place to state the policy and a poor place to enforce it. For anything involving money I would also enforce limits in the backend, as the commerce tools pattern above does.
The scale problem
The last technical slide asked how an agent can browse thousands of products. The “scale problem” answer was a query, retrieve and refine cycle, with these best practices: real-time inventory APIs (UCP), top N candidates rather than the whole catalogue, let the AI rank and select, and expose filters such as price and category. The session then pointed to a hands-on workshop, “Build an agentic commerce solution”, at 13:30 and 15:30 in the Hall 3 workshop area.
The scale problem: give the agent a short, filtered candidate list, not the whole catalogue.
