And if I just want to take away, if you stop listening for the rest of the presentation, discovery and exploration benefit from non-determinism, right? So the amazing thing about LLMs is huge corporate 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's 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 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 uh 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 is our main question. So, um we probably we're going to zoom through this cuz all we talked about today is agents, I imagine. So, uh 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? Um again, we all know this, but uh crudely, an agent is just calling LM and calling tools. They're spending both of them. Um 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, uh what are the main problems? Um 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 uh in sort of the open class style, let's just let the robot operate a human operate Well, hopefully not operate a human, but uh concerning slip, uh hopefully it doesn't come true. Let the robot just operate the browser like a human. Um So, wrong place. Well, first, how does an agent certify it's in the right place or domain? Um how do I know that, you know, maybe the the website looks a lot like, you know, amazon.com, but is, you know, amazon. whatever and and is a fake one. Um the wrong thing. Uh 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, you know, uh buy something that's 10 times more expensive. The wrong amount. Um you know, 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. Like, the number you 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. Um you could paste your credit card, it could go the wrong place. Um, but, you know, as 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 basic approach of taking a card number, bad. Browsing a site can be finicky, filling forms, clicking pay, it's all slow, um, 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 MSPs and uh, APIs exist.

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, um, you know, first, not all payment methods are, you know, universal like credit cards. Um, some are expressed in different ways. Um, 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 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 sort of like 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, you know, duped by a domain or you know, haven't parsed the amount correctly, I can still apply what I think is right 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 um kind of a common Stripe integration. So, I have my seller Stripe account and I want to charge uh $50. So, I 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. Um 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 Stripe account. And it's going to provision a shared payment token. Let's say it collect 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.

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, um we still send that information over. So, the 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 exact their previous uh risk systems um so that, you know, they they can accept payment. Um, but what we'll see is we actually had a failure here. So, the request amount, which was $50, is greater than the amount that was uh mandated. So, again, we like 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, uh again, like this would work across any payment method type, and, you know, now that we you know, can lower the cost, we'll see that uh this actually goes through. Yep, that payment went through. So, now we're able to securely send a credential, apply limits, make sure there's a minimized blast radius, um and still allow the seller to process payments as they normally would.

So, um we've covered uh Uh, how do we get credentials, how do we know to pay for them and associate with the actual product we're buying? So, again, um closing that window of of improved determinism. Um So, maximize determinism. Let's do demo. So, now if we jump over here, I'm going to start a server. This server's a regular sort of uh 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. Make a curl request to it. It fails. Tells us that we need to pay. It gives us some uh encoded payload that explains what we're buying and who we're paying for and the what we're paying for and the mechanism to pay for it. Um and I can go ahead and uh 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 um this to this particular recipient. Um it'll be path USD on the tempo blockchain. And I can go ahead and approve it. So, now that goes through, get our success, and then we can see a transaction landed on the blockchain. So, uh we're, you know, able to create credentials that have limited use. Now we can be uh told by a seller how they want money and have it be associated with the actual re- resource I'm requesting. And now I can send them funds.

Um but the last part is um let's just jump back in. It's like we're not always buying API calls, right? And sometimes the details uh of the purchase matter quite a bit, right? The tax amount, maybe there's that, there's uh 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, you know, the the robot, you know, 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 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 Open AI 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 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 called 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 spin 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 um is the robot-friendly way of looking at it. So, um the ACP protocol or 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, uh Uh, 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, you know, pull information, you know, out of a UI like this, it has structured data that I can refer to. So, uh, the line items, the base price of each, applicable tax, the different fulfillment options, and so on. So, nothing surprising here, but, you know, our goal is to sort of establish that determinism, right? Where like we've segued from discovery, where maybe we were doing some web crawling, now we've transitioned to just purely programmatic back and forth. So, you know, as I change payment methods or I change shipping, and ultimately pay, those back and forth happen. Payments goes through using something like a shared payment token or otherwise to relay those credentials. Let me check again. Yep.

So, you know, at the end we 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 customer, but also receive the signals um 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 with our products, but, you know, we want to make our products agent-friendly. Um, and if we only expose you web UIs or or or applications like that, um we increase the likelihood of non, you know, the non-determinism interacting with our businesses. Instead, we should make them age friend agent-friendly um 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 um is then important for agents so that they're able to uh yeah, not accidentally spend a gazillion dollars on a card.

Um so TLDR, discovery we should keep with non-determinism that's perfect. Payments and checkout and credentials we want to shift towards exclusively deterministic. Um so non-deterministic planner and constraints with verifiable parties and structured negotiation results in a small radius of risk and hopefully safe uh payments between agents and businesses. So that's all I got. Thank you.

I have 2 minutes and 9 seconds if people have questions.

You mentioned blockchain. Yeah. What is this hosted by Temple or is it Stripe or do they own their own separate data? Yeah, so um you know, Stripe supports a number of different uh protocols and and a uh variety of networks including Base and Tempo. The transaction data uh innately lives on those chains and then Stripe replicates the sort of product view of that data in our own system. Yep. But why factor This guy. Um the shared payment tokens are really cool. Uh in terms of say like recurring budgets and payments, like I'm thinking of you know, I want to give Open Claw $25 a week to use with like a particular model. How how does that uh kind of factor in? Yeah, so you touched on two points the sort of the subscription thing and then sort of more enduring policies. Um on the subscription side um in the same way you give a credit card to a business and you permit it to spend $25 or whatever on a on a periodic basis but it still uses the same credential. Uh 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 uh subsequent usage. Um and then on the another part about like uh uh 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. Um so I'm wondering is Stripe projects just effectively a wrapper of these primitives that you've discussed during the session? Uh 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 SAS business can express their products as And then the point touched on the recurring part is how the monthly part would work. Thank you. You mentioned that you have started this 2 years ago. I'm wondering about the the number of such payments done and the volume If you can share something 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. Well, I'm at zero now, so thank you everyone. Appreciate it.