Building safe Payment Infrastructure for the autonomous economy — Steve Kaliski, Stripe

I just want to thank everyone for being here. 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. I spent my first 4 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, increasingly for robots.

In the last 2 years, I've been exploring how to let robots spend money, and how Stripe businesses can adapt to that new kind of buyer. And if I have just one takeaway, if you stop listening for the rest of the presentation: discovery and exploration benefit from non-determinism,right?

So the amazing thing about LMs is a huge corpus of information—the world's information—can predict and recommend code, or products, or businesses for you. But credentials, payments, and checkout require determinism, so not just benefit from it, but require it.

So that sort of isolation of "how do I find things," or "what should I do," from "how am I going to transact," is sort of the critical separation. So we're going to talk about agents as economic actors, all the bad things that can happen, the solutions that Stripe and our partners have worked together on to fix those, and then a little bit of what's next.

So, again, maybe another takeaway: agents are already economic actors,right? They have their own currency and tokens. So as you are in Cloud Code, or Codex, or any other kind of application, you were, in effect, spending money,right? It might be proxied through the subscription you have, or converted from the tokens that are being inputted or outputted, turning into dollars.

But in effect, we're already letting them spend,right? Just not with any business but the LM provider that they're working with. So how do we enable other currencies, and other spend patterns, and other payment methods, and other business interactions is our main question.

So we probably—we're going to zoom through this because all we've talked about today is agents, I imagine. So agents produce text. Sometimes they need to read or write data, or interact with third parties. They do so using tools, and sometimes those tools require money.

So how do we safely enable this? Again, we all know this, but crudely, an agent is just calling an LM and calling tools. There's spend in both of them. And the tools in particular we're going to talk about are search, credential management, and payment.

It's the magic, but it's also the risk. So what are the main problems? I can buy from the wrong place. I can buy the wrong thing. I can spend the wrong amount. I can use the wrong credential. So the base approach, sort of the open-cloth style, it's just let the robot operate a human—operate, well, hopefully not operate a human, but—concerning slip, hopefully it doesn't come true.

Let the robot just operate the browser like a human. So wrong place. Well, first, how does an agent certify it's in theright place or domain? How do I know that? Maybe the website looks a lot like amazon.com, but is amazon.whatever, and is a fake one.

The wrong thing. You could stumble through a site looking for a purple T-shirt, and you could, maybe less concerningly, buy an orange T-shirt, but you could also buy something that's 10 times more expensive. The wrong amount. As we know, at least for me, I've seen totally different prices here than back at home.

Prices can drift. There's miscalculations, different currencies, taxes, and so on. The number your robot may extract from the page may not actually be the amount of money that you want to spend. And of course, wrong credential. You could paste a credit card.

You could go the wrong place. But as here, there are other different payment methods that are hard, or if not impossible, for an agent to relay. So we want to be able to solve all four of those things.

And again, the base approach of taking a card number, bad. Browsing a site can be finicky, filling forms, clicking pay, it's all slow, hard-to-observe outcomes. And this isn't unique to payments,right? It's the same as operating any web app, or anything that has a monetary risk.

And that's why MCPs and APIs exist. So in Stripe parlance, the left-hand side dashboard is for a human, and theright-hand side robots prefer code. So the ideal approach is something where we can bind to a merchant. We can enforce spend policies.

It can be API-driven and thus programmatic, and you can have verifiable identities. So I'm going to talk about three different things that Stripe and our partners have built together around credentials, payment flows, and checkout, to illustrate how we're trying to solve all of those problems.

So first, I want to talk about shared payment tokens. And the idea here is that, first, not all payment methods are universal like credit cards. Some are expressed in different ways. But there's also no way to enforce spend limits or controls when you just hand a card number to someone else,right?

You're going to trust them that they charge the amount that you parsed out of the page or whatnot. And what we built with shared payment tokens is this idea that an agent can collect a payment credential, and it can share it with the seller across hundreds of different payment method types, and it can encode, sort of like a mandate or smart contract, the limitations of that credential to be used by a particular seller.

So we'll do a demo in a second, but I can apply usage limits to specific currencies, to amounts, for time, and a particular seller. So even if I've been duped by a domain, or haven't parsed the amount correctly, I can still apply what I think isright in terms of the amount and the particular seller that I'm targeting.

So again, scope to seller. It's enforced by Stripe, works across payment methods, and it's auditable. So I'm going to jump into a quick demo just to show you how that works. So

let's look at kind of a common Stripe integration. So I have my seller's Stripe account, and I want to charge $50. So normally I would create a payment intent, and on line 39 I'd collect that payment method myself, and it would run, and that's all great.

But now, instead of collecting the payment method on my website, an agent is collecting a payment method that it may have already received from its human operator, or through the subscription that backs the harness, or whatever it may be.

So we're going to introduce a second Stripe account, and this is the agent's Stripe account. And it's going to provision a shared payment token. Let's say it had collected a Visa card, and it's going to say that this Visa card, which has a much higher credit limit, is only going to work for $25, and it's only going to work for the next 30 days, and it's scoped to this particular seller, illustratively my internal test account.

So we're going to go ahead and we're going to create that credential. And instead of the seller using a payment method that they've collected, they're going to receive a token that's been granted to them and try to run the payment.

So let's—cool. So the first thing we see is that we created that new shared payment token, which applies to that Visa card. It's active. It has that $25 limit, and it's going to expire in 30 days. Now, what's important as part of this also is we don't want the seller to be fully hidden from what's happening.

So in the same way that they would have otherwise collected a card and knew the brand and knew the last four and so on, we still send that information over. So the brand and the last four, the credit type, they can use all these inputs in their existing risk analysis.

So an important part here too is that we're not trying to do something secret from the seller. We still want to provide the relevant information to the seller so that they can still apply their previous risk systems so that they can accept payment.

But what we'll see is we actually had a failure here. So the requested amount, which was $50, is greater than the amount that was mandated. So again, we collected a credential, we shared it, we applied a limit, we trusted the seller, the seller tried to do more, and now Stripe enforced a limitation.

So again, this would work across any payment method type. And now that we can lower the cost, we'll see that this actually goes through. Yep, that payment went through. So now we're able to securely send credentials, apply limits, make sure there's a minimized blast radius, and still allow the seller to process payments as they normally would.

Now, that covers credential sharing, but there's two more parts to this. It's how do we actually associate payment to a product, and then how do we do checkout. So the second thing we built, we worked with our friends at Tempo, was what we call the machine payments protocol.

So back to that original point around tool calls. Well, tool calls are just sort of HTTP requests that agents can make. And HTTP requests should be able to be paid for,right? So one way is you pass in an API key, but sometimes those interactions with tools can be ephemeral.

So we want to be able to communicate the need to pay in those HTTP requests by returning a forward to status code, and then supply that credential that we showed earlier so that we can actually get a good back.

So we've covered how do we get credentials, how do we know to pay for them, and associate it with the actual product we're buying. So again, closing that window of improved determinism. So maximizing determinism. Let's do a demo.

So now if we jump over here, I'm going to start a server. This server is a regular sort of web server. It has protected endpoints that now require payment. So let's say my robot is calling one of these endpoints to try to execute a tool.

We'll make a curl request to it. It fails. It tells us that we need to pay. It gives us some encoded payload that explains what we're buying and who we're paying for, and what we're paying for, and the mechanism to pay for it.

And I can go ahead and

pay for it now. So now we get some extra information back because we're speaking that protocol. We can see that it's going to cost a penny to this particular recipient. It'll be path USD on the Tempo blockchain. And I can go ahead and approve it.

So now that goes through. We get our success, and then we can see a transaction landed on the blockchain. So we're able to create credentials that have limited use. Now we can be told by a seller how they want money, and have it be associated with the actual resource I'm requesting, and I can send them funds.

But the last part is—let's just jump back in. We're not always buying API calls,right? And sometimes the details of the purchase matter quite a bit,right? The tax amount, maybe there's VAT, there's restrictions about the amount of things I could buy, all the things that a typical e-commerce site is trying to convey.

And to that earlier point around the robot stumbling around a checkout page, there are a lot of details that we want to be able to relay back to the agent, and ultimately back to the human buyer, to make sure that the thing we're buying is the thing we think we're buying,right?

We want to minimize disputes and chargebacks and so on. And if we have this proxy layer of the agent in between, we run the risk of incorrectly relaying those details. So what we built with OpenAI, being the agent e-commerce protocol, is a standard set of APIs and objects that can explain how checkouts work across the web.

So similar to the last thing we showed where the seller kind of conveys the need to pay, we establish a back and forth between agent, a seller, and their PSP, where every single time the agent wants to create a checkout, or update the quantity, or pick a shipping amount, the seller can relay, sort of like a tool call, relay back the latest state, respond to that request, and ultimately result in payment.

So we can sort of illustrate how this works with a real business. Let's just turn up a server here.

So Stripe operates something called Stripe Press. It's our store of books. This is obviously a very cool, human-friendly way to look at it, but our equivalency is the robot-friendly way of looking at it. So the ACP protocol, or the ACP, covers a few things.

How do we express a product catalog,right? So instead of the robot stumbling around and having to click on links and figure out what to buy, we can express our products just in JSON with images and descriptions and pricing.

And then the robot can pick one of those and initiate a checkout. So we can pull up a familiar UI. Maybe I'm asking for recommendations about AI books. And on theright-hand side, we'll see the requests that the agent makes.

So it tells a little bit about the buyer, the line items, and quantity it wants. And then the seller can relay back basically the state of the cart. So instead of the robot trying to pull information out of a UI like this, it has structured data that it can refer to.

So the line items, the base price of each, applicable tax, the different fulfillment options, and so on. So nothing surprising here, but our goal is to sort of establish that determinism,right? We've segwayed from discovery, where maybe we were doing some web crawling, now we've transitioned to just purely programmatic back and forths.

So as I change payment methods, or I change shipping, and ultimately pay, those back and forths happen. Payments go through using something like a shared payment token, or otherwise, to relay those credentials.

Yep. So at the end, we have API-driven commerce flows that are flexible to different payment methods, whether they're crypto, or cards, or any of the other hundreds of payments that exist. And critically, the seller remains in control. They continue to have the relationship that they expect to have with the customer, but also receive the signals and risk data that they need to safely interact with agents.

And sort of it goes without saying, most of us have already done this with our products, but we want to make our products agent-friendly. And if we only expose web UIs or applications like that, we increase the likelihood of the nondeterministic interacting with our businesses.

Instead, we should make them agent-friendly to maximize the deterministic flows that agents have with our businesses. So leveraging things like shared payment tokens, or wallets, or other technologies to then manage those credentials safely is then important for agents so that they're able to

not accidentally spend a good billion dollars on a card. So TL;DR, discovery, we should keep with nondeterministic. That's perfect. Payments, and checkout, and credentials, we want to shift towards exclusively deterministic. So nondeterministic planner and constraints with verifiable parties and structured negotiation results in a small radius of risk, and hopefully safe payments between agents and businesses.

So that's all I got. Thank you.

I have two minutes and nine seconds if people have questions.

You mentioned blockchain.

Yeah.

Is this hosted by Tempo or Stripe, or who owns that data?

Yeah, so Stripe supports a number of different protocols and a variety of networks, including Base and Tempo. So the transaction data innately lives on those chains, and then Stripe replicates the sort of product view of that data in our own system.

The Wi-Fi.

This guy.

The shared payment token is really cool. In terms of, say, recurring budgets and payments, I'm thinking of I want to give OpenClaw $25 a week to use for a particular model. How does that kind of factor in?

Yeah, so you touched on two points. Sort of the subscription thing, and then sort of more enduring policies. On the subscription side, in the same way you give a credit card to a business and you permit it to spend $25 or whatever on a periodic basis, but it still uses the same credential, we have a similar idea there as well.

Sort of similar to in OAuth, access and refresh flow, where you can sort of request subsequent usage. And then on the other part about sort of more balanced budgets, the sort of equivalency can work here where you just pick a higher number.

We still scope it to individual sellers, but you could just create infinite of them.

So I'm wondering, is Stripe projects just effectively a wrapper of these primitives that you've discussed during the session?

Yes. Thank you for that plug. I did not have time to include that, but yes, Stripe projects is built on shared payment tokens, and then the mannerism in which a seller or SaaS business can express their products is the idea.

And then the point you touched on, the recurring part, is how the monthly part would work.

Thank you.

You mentioned that you have started this two years ago. I'm wondering about the number of such payments done and the volume of money moved.

We don't have public stats on any of that, but I think in general we're very encouraged by it, and we're really excited about trying to support more businesses in accepting that type of payment.

Okay.

Well, I'm at zero now, so. Thank you, everyone. Appreciate it.