SPEAKER_04
I just want to thank everyone for being here. I'm from Stripe. 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 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, increasingly for robots. In the last two years, I've been exploring how to let robots spend money, and how Stripe businesses can adapt to that new kind of buyer.
SPEAKER_04
And if I have just one takeaway, if you stopped listening for the rest of the presentation, discovery and exploration benefit from non-determinism. So the amazing thing about LMs is this huge corpus of information. The world's information can predict and recommend code, or products, or businesses for you. But credentials, payments, and checkouts require determinism. So not just benefit from it, but require it. So that isolation of how do I find things, or what should I do from how am I going to transact is the critical separation. So we're going to talk about agents as economic actors, all the bad things that can happen,
SPEAKER_04
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 are in effect spending money. 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
SPEAKER_04
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 want 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 LM and calling tools. There's spend in both of them. And the tools in particular we're going to
SPEAKER_04
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. The open clause style, let's just let the robot operate a human, 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 the right 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?
SPEAKER_04
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 robots 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, you know, as here, there are other different payment methods
SPEAKER_04
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 basic 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, you know, 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, you know, in Stripe parlance, the left-hand side dashboard is for a human. On the right-hand side, robots prefer code. So, the ideal approach is something where we can bind to a merchant. We can enforce spend policies.
SPEAKER_04
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, you know, 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
SPEAKER_04
else. Right? You're going to trust them that they charge the amount that you've 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, you know, across hundreds of different payment method types. And it can encode a mandate or smart contract the limitations of that credential to be used by a particular seller. So, you know, 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,
SPEAKER_04
I can still apply what I think is right in terms of the amount in the particular seller that I'm targeting. So, again, scope to a seller. It's enforced by Stripe, works across payment methods, and it's auditable. So, we're going to jump into a quick demo just to show you how that works. So, let's look at 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
SPEAKER_04
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 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.
SPEAKER_04
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 Stripe account. And it's going to provision a share 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.
SPEAKER_04
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 still enforces limitations. 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, and 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 of this: 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 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 response. So, we've covered how do we get credentials, how do we know to pay for them, and associate with the actual product we're buying. So, again, closing that window of improved determinism, so maximizing determinism. Let's do a demo.
SPEAKER_04
So, now if we jump over here, I'm going to start a server. This server's a regular 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 paid 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. It's that we're not always buying API calls. And sometimes the details of the purchase matter quite a bit. Right. The tax amount, maybe there's that. There's restrictions about the amount of things I can 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. 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 to 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 conveys the need to pay, we established 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 back the latest state, respond to that request, and ultimately result in payment. So, we can illustrate how this works with a real business. So, Stripe operates something called Stripe Press. It's our store of books. And 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? So, instead of the robot stumbling around and having to click on links and figure out what to buy, we can express our products 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 the right-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 establish that determinism.
SPEAKER_04
So, we can pull up a familiar UI. Maybe I'm asking for recommendations about AI books. And on the right-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 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 establish that determinism. Right? We've segued from discovery where maybe we're doing some web crawling.
SPEAKER_04
Now, we've transitioned to purely programmatic back and forths. So, as I change payment methods or I change shipping and ultimately pay, those back and forths happen. Payment goes through using something like a shared payment token or otherwise to relay those credentials. 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 expected to have with the customer, but also receive the signals and risk data that they need to safely interact with agents.
SPEAKER_04
And 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 non-determinism interacting with our businesses. And 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 manage those credentials safely is important for agents so that they're able to not accidentally spend a gajillion dollars on a card. So, TLDR, discovery we should keep with non-determinism. That's perfect.
SPEAKER_04
Payments and checkout and credentials we want to shift towards exclusively deterministic. So, non-deterministic 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.
SPEAKER_04
You mentioned blockchain. Yeah. What is this hosted by Tempo or Stripe or do I know 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 product view of that data in our own system.
SPEAKER_04
I like that. This guy. The shared payment token is really cool. In terms of recurring budgets and payments, I'm thinking of, I want to give OpenClaw $25 a week to use with a particular model. How does that factor in? Yeah, so you touched on two points. 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.
SPEAKER_04
Similar to OAuth access and refresh flow where you can request subsequent usage. And then on the other part about 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.
SPEAKER_04
So I'm wondering if Stripe projects is 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.
SPEAKER_04
And then the manner 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 money moves. 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 and accepting that type of payment. Okay. Well, I'm at zero now. So thank you everyone. Appreciate it. And on the right-hand side, we'll see the requests that the agent makes.
SPEAKER_04
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're like, we've segued from discovery where maybe we're doing some web crawling. Now, we've transitioned to just purely programmatic back and forths.
SPEAKER_04
So, you know, as I change payment methods or I change shipping and ultimately pay, those back and forths happen. Payment goes through using something like a shared payment token or otherwise to relay those credentials.
SPEAKER_04
So, you know, 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 expected to have with the customer, but also receive the signals and risk data that they need to safely interact with agents. And sort of the, you know, goes without saying, most of us have already done this with our products, but, you know, we want to make our products agent-friendly. And if we only expose web UIs or applications like that, we increase the likelihood of non,
SPEAKER_04
you know, the non-determinism interacting with our businesses. And 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, you know, not accidentally spend a gajillion dollars on a card. So, TLDR, discovery we should keep with non-determinism. That's perfect. Payments and checkout and credentials we want to shift towards exclusively deterministic.
SPEAKER_04
So, non-deterministic 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.
SPEAKER_04
I have two minutes and nine seconds if people have questions. You mentioned blockchain. Yeah. What is this hosted by Tempo or Stripe or do I know that data? Yeah, so, you know, 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. I like that. This guy. The shared payment token is really cool. In terms of say like recurring budgets and payments, like I'm thinking of, you know, I want to give OpenClaw $25 a week to use with like a particular model. How does that kind of factor in?
SPEAKER_04
Yeah, so you touched on two points. 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 like request subsequent usage. And then on the another part about like 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.
SPEAKER_04
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 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 money moves. We don't have public stats on any of that, but I think in general we're very encouraged by it
SPEAKER_04
and we're really excited about trying to support more businesses and accepting that type of payment. Okay.
SPEAKER_04
Well, I'm at zero now. So thank you everyone. Appreciate it.