The Rise of Agentic Commerce — Emily Glassberg Sands (Stripe)

Delighted to be here. Thanks for having me.

Well, Stripe builds programmable financial infrastructure. So, put kind of less buzzwordy, we are giving any business, whether it's a 20-year-old selling a Figma template or now more than half of the Fortune 100, the rails and the intelligence to move money online and to grow faster. You asked about the numbers: $1.4 trillion on Stripe, 3% of global GDP. And that number grew 38% year over year in what many experienced as kind of a rocky macroclimate. Stripe's network handles, on average, about 50,000 new transactions every minute.

$1.4 trillion in payment volume processed annually, and every one of those transactions is training data for some of the AI systems that we will talk about today. I'll just say, because of the flywheel, Stripe is no longer the payments API. If we were talking 10 years ago, we'd be talking about a payments company, but in practice, we're optimizing now the entire payments lifecycle: the checkout user experience, fraud prevention, bank routing, automatic card update retries, even how you handle disputes as a business. And that's all in service of merchants' profits, right?

Growing their revenue and reducing their costs. And so, I think of sort of the tools we're creating as generating a structural tailwind for the internet economy, for growth in any environment. And we're already seeing it: businesses on Stripe grew seven times faster last year than the S&P 500. So, it's that infrastructure creating a structural tailwind for growth. That's our primary focus.

Yeah, our information org is really focused on three things. One is, how do we use data effectively? And that's end-to-end. How do we do the data engineering and analytics and internal science? How do we build ML-powered applications for our users? The second thing the information org works on is growth in the self-serve business. So, millions of businesses run on Stripe. The vast, vast majority of them, and almost all of the SMBs and startups, get going directly in our product. And so building that product-led growth, front-door experience for users is sort of our second focus area.

And then the third thing we work on is experimental projects, which I have mixed feelings on as a name because I think innovation and experimentation is so important, and it can and should and does happen everywhere. But the concept of an experimental projects team is really just having a couple dozen standout engineers and PMs who can go run ahead at really big, perishable, meaty opportunities that we couldn't easily staff from within any of our current product verticals. So information is data, self-serve, and experimental projects.

I think I've kind of just always chased puzzles where better data, better understanding unlocks outsized social impact. That's what drew me into academia. So, at Harvard, I was an econ PhD and ran a bunch of field experiments that exposed hidden frictions, right? Like, why do referrals dominate hiring? Why are female playwrights so underproduced? And got a lot of pleasure from seeing policies shift, decision-making shift, incentives shift once the evidence was clear. Going to Coursera for me was really about translating that impulse into product, right?

In 2014, I was in my fourth year of the PhD program. I graduated a little bit early, so coming up on graduation, and I said, hey, where do I think this obsession with better data unlocking outsized social impact is most going to matter? Is it going to be in writing papers, or is it going to be in diving into, in this case, edtech? And Coursera was super small at the time. It was less than 40 folks, but what it turned into was AI-driven learning paths and skills-based hiring tools that opened opportunity for tens of millions, eventually hundreds of millions, of learners around the globe.

And I was there about eight years, and the transition to Stripe was really like the same mission at economic scale. Stripe is about equalizing access to creating a company and reaching customers globally for businesses everywhere. And I'm an economist by training, so I really care a lot about incentives. And I think a thing that struck me from my first conversation with Patrick was how aligned incentives are between what Stripe wants and what the businesses running on Stripe want.

So, like, if a coffee roaster in Berlin sells more, right, Stripe grows, and so does internet GDP. And so, that ability to build and ship any product that makes a business more successful without even really needing to worry about first-order monetization of that product, right? Because we, in most cases, already sit on monetization of the payments infrastructure, which is really exciting for me and kind of kid-in-a-candy-shop. And that's all manifested over the last almost four years now.

The only other thing I'll add about the Stripe pull was just, like, the dataset here is kind of like looking at a macro MRI. It's like a real-time image of the global economy that we can then actually action and improve. And so, that's a little bit of economist catnip.

We've, I think, all seen and are all experiencing this sort of explosion of impact from foundation models that are trained on broad data and that can then be adapted for a bunch of downstream tasks, right? So GPT for language, or diffusion for images, or TimeGPT for time series. And in each case, the trick is kind of the same, which is there's a transformer, and it soaks up incredibly diverse data. It learns a kind of dense embedding space. And then later, you fine-tune or prompt it for whatever job you need.

To your kind of push earlier, I think if you're doing a pretty standard image thing or you're doing a pretty standard language thing, you should for sure use out-of-the-box LLMs with some prompting or some fine-tuning. Maybe we'll talk later about the AI economy that we're seeing, but there is just a wealth of really cool applied AI companies solving vertical problems that start out just as pretty simple wrappers. Wrappers is sometimes said in kind of a derogatory way, which I think actually misses the point.

These businesses are bringing real context and real relationships and real incremental data to build that wrapper-differentiated product experience. But I totally agree with the general sentiment that for many, most businesses, and certainly many, most startups who don't have access to any kind of proprietary data, start with out-of-the-box LLMs. Stripe is a little bit different, right? Four trillion a year in payments volume flowing through us. And that's data that's like, OpenAI doesn't have that data, Anthropic doesn't have that data. And it's a pretty different problem in some ways, not in all ways, but in some ways.

Than a language problem, and certainly quite different than an image problem. And this isn't our first time putting that data to use. It's been well over a decade at Stripe that we've relied on specialized ML systems, right? We have Radar for fraud, we have Adaptive Acceptance for soft declines, but each of those models is sort of a narrow, single-task model, and each of those models historically only saw kind of a sliver of reality. And so last year, we were stepping back and looking at what foundation models can do and recognizing that we're logging tens of billions of transactions.

And at that density, actually, payments, while a different problem than language, start to look like language in some ways. There's an agreed-upon syntax, right? There's the BIN and the MCC and the amount. There's sort of some longer-range semantics, like, is this device reuse? What's the merchant history? Where is it in the card lifecycle? In a similar way to how language transformers learn an embedding space where words with similar meanings cluster together, we thought, hey, intuitively, at our scale, and given how payments data is structured, we could probably learn payments embeddings as well, or it's at least worth a shot.

I would say the thing that's most interesting to me about the analogy between language and payments is, in language, words have a meaning in relation to the other words around them. And in much the same way, a payment has a meaning in relation to the other payments around it. And so with our foundation model, what we're really asking is, like, what if every charge got its own vector in a similar space? And then, as each new charge comes in, you place it in that many-dimensional space and understand where it sits in relation to, for example, a known card-testing attack, or known fraud, or a known merchant issue.

The other thing I'll note about learning these embeddings is it doesn't require any labels, right? It's fully unsupervised. So, jumping back to the specialized models, fraud, auth, disputes, those work because of the labels. But being able to do a fully unsupervised approach means you can actually use all of the tens of billions of transactions. You can adopt it at very large scales. You don't have to constrain to the subsets of data where you have relevant labels. And so I guess the simple description of why a payment foundation model has turned out to work is, like, how much data can we learn from?

So, literally all of Stripe's history, not just some task-specific subset. How richly we learn. So, these very dense embeddings capture subtle interactions and similarities among charges that manual features or counter features will totally miss. And then the third, and this is more operational, but I think it matters given the pace of AI, is just how efficiently we can build. Like, we now have these shared embeddings. They're available in Shepherd, which is our shared feature store, which we actually co-built with Airbnb and have open-sourced under the name Cronon.

But, like, it makes spinning up a new model become a weekend project, not a quarter project, because you get, kind of out of the box, these embeddings.

So, yes. And I think we will get to a point where it fully replaces. Today, it is, as you put it, an ensemble, but it's an even more nuanced ensemble, which is it's an ensemble within a problem space. So, take the example of card testing. Card testing is when a fraudster is trying to find cards that work, either so that they can use them later for fraudulent purchases or so that they can sell them to other fraudsters to use. There are labeled examples of card testing.

There are traditional machine learning models that Stripe has and has invested in substantially to identify and block card testing, but there are important slices of card testing that traditional methods just literally can't see. So, if you think about a global online retailer, they might see hundreds of thousands of legitimate purchases in an hour. Fraudsters might slip in a few hundred 37-cent authorizations, way too dilute for any of your traditional models to catch. The foundation model is basically watching the sequences in the way that you'd watch frames in a movie, right?

So it sees 200 near-identical requests, same low-entropy user agent, maybe rotating the proxy IPs, maybe spaced like 40 seconds apart or something, right? And they light up kind of this red island that denotes card testing and can get blocked. And so what's unique about that is the number of clusters can be very large. There's a lot of different card testing attacks that can be happening, but the number of labels that are needed to correctly classify a cluster is actually quite small.

You really just have to know that, if the cluster is tight enough, there's some evidence of card testing there to know that the whole cluster is card testing. And so, given the size of the Stripe network, we can find labels for even very small clusters, which is what boosts our recall, right? So in this case, we ensembled together the existing traditional card testing models with this classifier classifying sequences of these foundation model embeddings, and our detection rate on large merchants went from 59% to 97%.

And so will we move to a world where eventually all card testing is detected by the foundation model? Maybe, but what's more interesting to us right now is solving the problems that couldn't previously be solved.

Yeah, well, so first of all, our first instinct was actually full-on wrong, right? Which is, like, let's just throw bigger transformers at single payments. I said earlier, oh, what's interesting about payments, sort of similar to language, is words only matter in relation to the words around them. Payments only matter in relation to the payments around them. But actually, that wasn't ex ante obvious to us. A lone payment record, you mentioned, is kind of sparse. It's also kind of boilerplate.

And after something like a billion tokens, the loss curve kind of flattened, right? Scaling wider wasn't going to be the answer. And so, we actually had to change the question. And instead of treating a payment as an isolated atom, we stitched charges together into these short histories, right, represented as sequences. Everything the same—I mean, there's lots of different types of sequences—but, like, everything the same card did in the past few minutes, everything that flowed through the same device on a Friday night, everything that this merchant's new BIN saw during some presale frenzy.

And then, kind of, like, the moment we trained on sequences, the model had fresh signal to learn, and kind of the curve started dropping again. And so, the backbone that we ended up with is a BERT encoder. And by the way, we also tried decoder-only model architectures like GPT, but BERT is better for understanding tasks, right? What we're really trying to generate is the embedding, the understanding of the payment, and then we put it in relation to other payments. And GPT is better for generation, right?

But we're not actually trying to generate in the first stage.

Yeah, it's a BERT encoder. And it definitely, like, you asked who did the work. We actually just originally had three MLEs who we put in a little bubble. They'd worked on risk-related problems in previous instantiations of their careers at Stripe, but we put them in a little bubble and said, think about the broad set of problems Stripe faces that might be solved by a foundation model, and choose a couple of steel threads, and then go see how much progress you can make against those steel threads.

But these folks were protected from day-to-day operational load, were protected from incidents, weren't running any production-grade systems at the time, and really operated more like a research team.

It actually wasn't, because the experimental group has only been around about a year and a half now. So we started this shortly before that, but same concept, right? They don't happen to report into that. They report into our ML Foundations team, but structurally it's the same idea and was part of, actually, the motivation for then scaling up experimental projects.

I mean, less of, yes, and still intense, yes. Definitely wasn't all smooth on the infrastructure side. We had to build a custom tokenizer and optimize it for Stripe events. We had to scale our data pipelines to grow to the very large data sizes I mentioned earlier. Previous models just hadn't trained on such large amounts of unstructured data all at once. We also had to build custom data loaders to make sure that GPU utilization was high. Earlier versions actually resulted in pretty low GPU utilization because data loaders became the bottleneck.

And so yes, that made training more expensive, but also it made it slower. And so, yeah, I mean, this was something bigger than we'd trained before. We had to add a bunch of checkpoints to make our runs more robust, intermittent failures, the kind of stuff that you would be doing anyway if you were an AI lab, but we are not first and foremost an AI lab. And so those were all sort of progressive builds for us.

When it came time to actually—so, running the model in shadow, we run all of our ML in shadow before we roll it out. Running in shadow was relatively straightforward. The first experiment, though, we ran in production had a bunch of latency and reliability requirements that put pressure on some of our systems. As you can imagine, these decisions have to be made in the charge path, so in real time. You have maybe dozens of milliseconds to make the decision. And actually, part of the reason that we were totally happy to start with this kind of ensemble model is we had a full fallback to the existing model in cases where we couldn't meet the latency requirements.

But yes, plenty learned in the journey.

My first reaction to that is LLMs are actually getting quite good at explainability, right? And so, to the extent that the model is seeing patterns, even patterns that humans couldn't enumerate, an LLM on top can say something like, high-velocity CVC mismatches on a new device are the explainable reason, the summary of this cluster. But I really do think of all of these defenses as like a two-step dance. There will always be room for rules.

Rules provide speed. Rules provide clarity. We ultimately put our users in the driver's seat. Users can write Radar rules. They can say, never accept first-time cards from this country over $1,000. And we actually, about a year and a half ago, released a tool called Radar Assistant that lets them type that in plain English and test it and ship it instantly without even having to write code. But then the models are really needed for nuance, right, for seeing the patterns that humans can't.

And when they conflict, historically, the rule won, right? Merchants keep ultimate veto power. But a few weeks ago, we actually updated our systems to blend the two even better. So, we call it dynamic risk-based rules. And how it works is, instead of the user writing a brute-force rule, like block every CVC mismatch or every postal mismatch, the rule can be blended with the model. So, like, block every CVC mismatch if the real-time model or the issuer score call it risky beyond some threshold.

What that allows is kind of the best of both worlds, right? There's always some good customer who fat-fingered, and they should be able to get through, but the sketchy traffic is still stopped. So I don't think transparency or explainability is yet 100% there. I think we will continue to use rules and models in parallel. And then there are, of course, just engineering and logging best practices around making sure you are storing the features that were used by the model and the model output so that ex post, if a user or a regulator comes and wants to understand what drove the decision beyond what you've logged, you can always reconstruct that cleanly.

There's so much enthusiasm about the latest models and the latest methods, and I think it's really easy to start with what can the models and the methods do, and then try to come up with a product from that. We like to start at the opposite end of the spectrum, which is the simple business task. What is the user pain that we are hearing or seeing? What metric best captures that user pain? And if we were to build an AI solution, ML solution, that nudges this metric by even a single percentage point, right, when you're talking about Stripe's scale, a single percentage point of improvement is a lot of money back to the businesses that run on us and the internet economy. Does moving that metric matter?

So, it starts with the user pain and the business need. And then we look at the data. It has to be plentiful. It has to be already flowing through Stripe's pipes. Doesn't mean we can't think expansively about what other data we'd like to be collecting over time, but you're not going to turn on an AI solution today if you don't have the data. And it has to either be amenable to unsupervised approaches, or we have to be able to label it well enough that the model can learn.

Is there the data, and is it structured in a way that's useful? And then finally, we like to ask just whether Stripe has a built-in advantage. Is this something we can do uniquely well because of our network? And that usually comes down to the shape of the data that enables it and the fact that we have that data in a way that other people may not. So, a recent example that might bring that to life a little more is our Smart Disputes product, which we announced just a few weeks back.

So, let's start with the user pain, the business need. Chargebacks are really painful. Merchants lose about $55 billion a year to chargebacks. And fighting disputes is also really costly for the business. Fighting a single dispute can mean putting together a 12-page evidence packet, digging up receipts, looking at IP logs, tracking down delivery confirmations, pasting everything into this dozen-page PDF. Most businesses are only bothered by the biggest-ticket items. And for lean teams, which includes basically all of the startups out there, they rarely bother.

It's just not worth their time. They don't have the expertise in-house. I was talking to a friend of mine the other day who runs a job marketplace, and she's one of the few marketplaces that monetizes off of the job seeker instead of monetizing off of the employer. And she's just getting crushed by disputes. And she told me, "Hey, Emily, it's crazy that these people are disputing because they're saying that they never used my service, but they've literally uploaded their résumé."

Nobody else has their résumé. Nobody else benefits from uploading their résumé. It's called friendly fraud, but that's kind of a misnomer because it's not friendly. But she literally doesn't fight them. She has all the evidence, but she doesn't fight them. And if you ask her, she's like, "It's just not worth my time to put together these crazy packets." Okay. So a small improvement in dispute win rates would translate into hundreds of millions of dollars across the Stripe network.

So this satisfies the first pillar: there's a real user pain and there's real business opportunity here. Then the second is, do we have the data? Well, we already see which disputes are being won and lost, of those that are being fought. We already store most of the data an issuer would want to see when it decides a chargeback. So it's a great candidate, which is why we launched Smart Disputes. And it's basically just a classifier that grades every incoming chargeback as it comes through on its likelihood of success.

And if the model thinks that the merchant can win, then we overlay this LLM-powered agent that goes out and gathers the right proof, like IP address matches for the digital services and screenshots of the usage and whatever the issuer historically prefers. And then it just bundles that evidence into the format that the bank expects and files the response without any human having to touch the case. And then, of course, it watches the ruling and then feeds the outcome back into training so it keeps getting smarter.

And Vimeo and Squarespace were our two first adopters, but they're recovering 13% more revenue on disputed charges from adopting it, and they're doing that with zero extra labor. You literally don't even have to click a button. You just toggle once to turn it on.

And then, the impact is even greater for these tiny merchants who never used to contest chargebacks at all, and they now have this AI paralegal that's working for them. And so, you weren't asking about Smart Disputes, you were asking about the mental model, but it's basically: big user pain, abundant Stripe-only data, a clear model-driven fix, and that's how we decide where the next place that Stripe AI should go.

For sure. And by the way, fraud done well also generates revenue, in the sense that the alternative is usually doing fraud poorly, which has a bunch of false positives, which means you're blocking some good users.

But the way we think about it is, we use AI across every stage of the payments lifecycle. So, from the second a customer lands on the checkout page all the way through to handling those refunds and disputes. And if you think about that lifecycle, there's kind of five meaty steps. There's checkout, there's authentication, there's fraud detection, which is where we've spent most of our time talking, there's authorization, and then there's the downstream events like refunds and disputes.

Checkout is sort of the easiest for you or me, pre-Stripe, to reason about because we all experience it as consumers. And I think we could all agree that checkout experiences feel pretty staid and inefficient. No matter who you are, no matter where you're shopping from, no matter how you like to pay, you usually get the same old form. It doesn't adapt. It doesn't know you. And a lot of times, that's all it takes for a customer to drop off at the finish line.

Some of that is little stuff, but some of that is big stuff. If I only have an Amex on me and Amex isn't shown, I literally would have to text my husband to get a Visa card. And if I'm in another country and have no access to any of the payment methods that are listed, then you've basically shut off my market entirely. So we've been working a lot on fixing that in checkout. AI is our magic wand here.

We call it Stripe's Optimized Checkout Suite, and it's just about making the checkout experience increasingly personalized for our users' customers. So, dynamically tailoring that experience to each of the end users, again, our users' users, in real time. So, Turo, maybe you've used it. They're the world's largest car-sharing marketplace.

They moved over to our Checkout Suite and saw a 5% increase in recaptured revenue, which for them was, I think, like $100-some million a year. Payment methods are a really interesting subcomponent of checkout. So, there has been a proliferation of payment methods in the world, which from a market efficiency perspective is probably a great thing. Stripe now supports well over 100 payment methods, like Apple Pay, iDEAL, buy now, pay later. And so, what we do in the Optimized Checkout Suite is: more payment methods is better for business because it comes kind of out of the box for businesses.

They can reach more customers with what they need. But actually showing more payment methods to their customers is suboptimal because people get choice anxiety. If they don't see what they need in the first three, they give up. And so we provide all these payment methods, but then we automatically surface the most relevant payment methods based on who the customer is and what they're buying. And it works. Businesses that show at least one relevant payment method beyond just cards see, like, a 12% increase in revenue and more than 7% lift in conversion.

So conversion goes up and the size of the transaction goes up. And that's a really big deal for something as small as the order of buttons on a screen. So that's checkout.

We use ML infrastructure that we've developed over time at Stripe and that relies on open source where available and sort of third-party buy solutions where it's not differentiated for us and where there's a third party that meets our reliability, latency, and cost consideration needs. So, for example, the data scientists and MLEs and even some of the software engineers here use notebooks for experimentation. We use Databricks notebooks. We use Flyte for orchestrating our training runs. We use NVIDIA GPUs and PyTorch for model training.

Feature computation, including those LLM embeddings and feature serving, is done in Shepherd, which, again, we built in partnership with Airbnb and have since open-sourced under the name of Chronon. Shepherd is new for us. Actually, we just completed the full migration to Shepherd a month and a half ago. That migration took on the order of about six months. But one lesson learned is to really make sure that we're investing sufficiently in the horizontal infrastructure layer so that individual product teams snap to the same infrastructure, versus allowing their golden workflows to diverge and everyone to spin their own.

Transparently, the original feature computation and feature serving system we built, which was called Semblance, had a number of limitations. It was pretty hard to develop on. And as a result, one of our largest machine learning groups at Stripe decided to fork, buy Tecton, a third-party solution. We couldn't adopt Tecton across Stripe because Tecton was only useful for batch solutions and didn't meet the latency and reliability requirements of the charge path. So, you could use it, for example, to score merchant risk at onboarding because you have a couple of minutes to make that decision, but you couldn't use it to score a charge because you have tens of milliseconds.

To make that decision. And we ended up in this fractured world, which led to all sorts of issues, including one of the most valuable signals for understanding whether a merchant is fraudulent is looking at the transactions that are happening on that merchant. Because there are certain patterns of transactions. Many of your buyers are from the same IP, or there's a big jump in prices. You used to be selling everything at $2, and suddenly you're selling everything at $2,000.

That in and of itself indicates that the merchant is fraudulent. And those features actually couldn't be shared because we were bifurcated. Plus, just from an investment perspective, you basically have mini ML infra teams within the applied teams that are operating inefficiently. And so, we brought all that together under Shepherd. It was a bit of a long journey, but it was definitely worth doing. And then we put enough work into it that we were like, we should just open-source it and make sure other people can build on it as well.

I think it results in us—it's a combination of the latency requirement and the reliability requirement, right? We run on five, six nines reliability. You can't have downtime. And that's not just downtime of the core payments APIs; downtime of the Radar API is super, super costly to the businesses that run on us. And so, the SLAs needed for us to be able to buy are quite high. There's also pretty stringent security requirements. So there are often new startups, less so on the infrastructure side and more so on the applied side, who we would love to buy from, partner with, but they don't have the security protocols and controls in place for us to feel comfortable operating in their stacks.

And so, I do think that the nature of what we are doing—the timeliness requirements, but also the reliability requirements and the security requirements—push us to... And I'm a big proponent of only build where you have a core competitive advantage, but on the margin, for our ML infra, [they] do push us a little bit more towards build than we would have in other contexts.

Well, reasoning models are on the rise, and with that, AI is no longer just about getting answers to your questions, right? It's starting to do things for you. I think most individuals first felt that—our individual aha moment was maybe with the shift from ChatGPT to Operator, right? Answer questions to going out and executing tasks in a browser. But that shift from knowing to doing is a big deal, and I think one of the earliest places we're seeing it's going to change things is commerce.

We've all seen those cool demos of agents buying stuff for people. At Stripe, we started leaning into this about a year ago, and back in November, we launched a toolkit that makes it easy for agents to transact on someone's behalf. So, I like coffee. I drink a lot of coffee. You might be able to tell by the pace of speaking, but there's this Barista agent that is out there today. And you tell it what kind of coffee you like, and then it just scours the internet for the best beans, and then it buys them for you.

But what's interesting about the Barista agent is it's not a traditional coffee shop. It doesn't own any of the inventory. It is literally just doing the discovery matching, plus I'll talk a little bit about the payments flows. That is the entirety of the app. And I think that's just a glimpse of how who is doing the buying is starting to shift. Agents are buying on behalf of humans. And then there's another big shift that's happening in parallel.

And by the way, both of these are early, but I think just given the pace at which we're seeing things change, we'll probably move pretty quickly here, is where the buying happens. So, more people and more businesses are spending time inside AI tools. And with that, product discovery and browsing, and now even buying, are starting to happen in those tools. Perplexity, you may have seen, recently launched hotel discovery and booking in the app, and it's powered by Stripe. But unlike most hotel discovery and booking surfaces you might think of, you're not linked out to a merchant website.

You aren't taken to separate checkouts. You stay within the Perplexity app. And I think that kind of in situ commerce is really interesting. We're also working with Hipcamp. It's summer season, so maybe a good time to mention this. They use agents to book campsites at state or national parks on the campers' behalf, even off-platform. The agent goes and completes the booking. They do it really safely with these virtual cards in terms of the money flow. And it just gives campers access to sites that aren't normally all bookable in one place.

Early days, the biggest change is around the money flows. But I would caveat, because people get really jumpy about, like, oh, an agent buying for me, that sounds super scary. I'd argue that in practice, agents have actually been buying for us for years. They were just human agents, right? When I order my salad from DoorDash, DoorDash charges my credit card, and then it issues a single-use virtual card to the driver, right? The driver is my human agent who goes and buys the salad on my behalf.

And they can only buy at Sweetgreen, and they can only buy for $25, and they can only buy in this two-hour window in my town. But it is, like, very controlled, and that single-use virtual card in the DoorDash case happens to be powered by Stripe. And so, what we're doing here in sort of the first, most simple iteration, your mental model should be: swap out the human agent for an AI agent, and that's how Barista Agent works, right? It's just using a single-use card from Stripe Issuing to make the purchase, just like the DoorDash driver does.

So the transaction's controlled, and your data stays safe. Now, I don't think that that will be the only mechanism for agentic commerce or the limit to what gets done. But it is sort of the first instantiation that we're seeing, is this difference in money movement, or replicating kind of human-agent money movement with machine agents. The other thing that's kind of interesting: those were all B2C, like consumer examples. But just like you and I are spending a bunch more time in ChatGPT or Perplexity or whatever we like to use, developers are spending a lot more time in Cursor and various AI dev tools to code faster.

And so another example of agentic commerce, which maybe isn't the first thing that comes to mind for people, is, like, you're in Cursor, you're building your product, you want to set up some front-end thing, bot protection, whatever, something like Vercel. Normally, what do you do? You stop coding, open a new tab, go to Vercel, sign up, get your API keys, bring them back to Cursor: total context switch. But now you can just buy Vercel from inside Cursor, right there in the code editor.

So you don't break your flow, it saves time for the user. It also creates a whole new channel for Vercel and Cursor to sell software directly right where the work is happening. So I mentioned in-situ commerce for the consumer, but this is in-situ commerce for the developer or B2B. And Stripe enables those transactions too. So I think there's a brave new world of agentic commerce, and who's doing the buying is different, and where they're doing the buying is different.

But there's a bunch of other stuff that's going to need to evolve too.

I don't know if you know Daphne Koller, but she hired me at Coursera. She co-founded Coursera back in the day. And I remember talking to her in the parking lot one night. She was notorious for staying very late, so it was always dark when we talked in the parking lot, and also driving very quickly. So you really had to get out of the parking lot before she got in her car. But she was saying to me in the parking lot late one night, everyone was so young, and half those people ended up married to each other.

We were there at all hours. Anyway, the first movie, the way she described it to me, was like, because we were talking about where do we need to evolve the learning platform and teaching platform to be? This was literally 2014. And I think her words were something like, the first movie was just filming a play on stage. And then you think about whatever today's latest Hollywood release is, and it's like this whole set of experiences that are only possible because it's on film.

And sort of the analogy she was drawing is like, the very first MOOC, literally what we had in 2014, Massive Open Online Course, was like recording Andrew Ng up in the front of his Stanford classroom, right? But today, companies like Coursera and Khan and whatever, we've actually built learning experiences that are only possible because of the data, because of the technology, because of what you can do through this new medium. And just bear with me, I kind of think it's going to be the same for commerce, right?

So the earliest versions of agentic commerce have looked a lot like swapping an AI agent for a human agent, right? Like, instead of the DoorDash driver doing it, the browser agent is doing it. And actually, we didn't talk about order intents, but one of the things that we're also enabling is right down to the agent navigating a web browser and filling out the human-optimized checkout form. And that feels like a very reasonable place to start. But that's not what agentic commerce will be, right?

Like, imagine now you're no longer selling to a person who's scrolling through your site. You're selling to a piece of software that has already read all the reviews and price-compared the market and is now in a hurry to kind of tick payments off its list. That's like how the AI agent is going to feel, and it's going to buy very differently from you and me. And so, we're still working through a ton of this. A ton of this is yet to be built, but you asked, what's it going to demand of Stripe?

And I think some high-level design principles: the first is just that intent is the interface, right? Humans click around; agents just declare what they want. So, in Perplexity, a traveler will type, "Find me a flight to New York under $300," but Perplexity is going to turn that sentence into a single JSON blob. It's like origin, destination, and budget cap. It's going to fire that at the seller. And so every merchant API is probably going to need one canonical intent endpoint that accepts those structured desires instead of this UI-click world that we live in today.

Second, I think it's pretty clear that product data is going to have to be machine-readable, right? I don't know if you've ever played around with United's fare database. It is not perfect for humans. Sometimes it's intentionally opaque for humans, but it is definitely useless for code. And so I think early adopters who want to sell through agentic channels are going to need to expose kind of an open product schema, like the SKU and the inventory and the price and the constraints, and maybe even the wedge that you're willing to give to the facilitator agent who's facilitating the commerce.

That's not CSS. That's not JavaScript. And then the agent's going to be able to run kind of a SKU-level search and know with cryptographic certainty, right? Flight UA263 for $250 is still available, right? So I think that'll change. I think latency budgets are going to shrink to machine time. We talked about latency budgets in the context of the charge path, but people will wait three seconds for a spinner. I think an agent's just going to retry somewhere else after a couple hundred milliseconds.

And so, it's all going to have to be pretty fast. And then, we touched on this briefly, but a ton's going to have to evolve in the risk space. Today, I think human buyers think of themselves as owning their credentials. I own my card numbers. Credentials are going to have to move from being possessed, being owned, to being permissioned, right?

Someone gets a one-time, scope-limited token to spend that $250 on United Airlines before midnight. And that token can't be used, replayed at another provider, and it evaporates after use, and it has all sorts of limits, whatever. Trust is going to have to be super programmable. Some developer IDE is going to be buying GPUs on behalf of 50 different startups and will want it to attach a verifiable business profile, including a risk score, so that downstream sellers can accept or refuse the purchase.

We're going to need a lot more observability. If you take the Hipcamp example, right, its camping bot should be able to book federal park campsites, but it also needs to be able to expose these real-time logs so that hosts can reverse anything that looks odd. And then it's probably obvious, but good bots need to be very distinguishable from bad bots. And a lot of the classic fraud tools might mistake a good bot as a bad bot, or just consider a bot to be bad.

Like, speed, data format, auth are all going to change when the buyer's a bot. And I think it's just going to require designing for intent, and publishing those structured catalogs, and signing and scoping every credential, instrumenting everything. And then we're all going to have to teach the risk stack to tell the good from the bad.

I think there's two bits. One is our own MCP server, and the other is how we enable MCP payments. They're different, but I think they're both kind of interesting in their own right. On the former, we talked a bunch about commerce-related examples, but there are AI agents out there now, probably a greater number actually than commerce agents, that are helping you run your business. So, not the transaction commerce part, but the running-your-business, like doing the boring admin stuff you hate.

So, generating the invoices off of messy spreadsheets and updating cards on file and changing billing plans, analyzing business metrics, and doing support stuff. And they're doing that without needing a human. And MCP, Model Context Protocol, is a critical enabler here. So yes, it can be agent-to-agent. MCP can also be a translator between LLMs and SaaS APIs, like more deterministic SaaS APIs. And so you can think of it as the simplest version is just the LLM reads a menu of tools.

So, for example, a menu of Stripe tools, and then when you ask a question, the model picks the right tool and fills in the JSON, and then the MCP server sort of fires, in this case, the actual Stripe call. And it's sort of the same principle as a browser hitting a REST endpoint, but the client is just a bot instead of a person. And so, what does this actually let you do today? Stripe's MCP server lets you do all the most common, kind of low-risk tasks that you can do on Stripe or through our API, right?

So, list customers or create customers or find your product prices or spin up a Payment Link or issue a refund or pull up your balance, like all of the kind of boring but essential stuff you do 100 times, right, while you're wiring up your Stripe integration or trying to serve your customers. One of the most interesting use cases I saw recently was actually Decagon. Are you familiar with them?

Yeah, so—

Customer AI. And in less than one week, one engineer at Decagon built an integration with Stripe through our MCP server that just lets Decagon's customer support agents securely access all of the info for their users, right? So, their users' invoicing info and subscription cancellations and whatever. So now, Decagon's customer support agent can, on behalf of the business, find the business's customers' invoicing info, or cancel their subscription, or deliver their refund directly from their customers' Stripe accounts. And the first Decagon customer that they released this to reported a 65% drop in support costs.

It's kind of striking how much of support is, cancel my subscription, give me a refund, explain my invoice, right? Stuff that actually can be done in a fully automated way if you have clean access to your Stripe systems. So where do we think this is going to go? I mean, it's pretty clear that MCP is becoming the default way that any single service, Stripe or GitHub or Notion, talks to an LLM. And so naturally, I think MCP also needs to support monetization, which is why we've enabled MCP payments.

So you can seamlessly monetize your MCP server using Stripe as well.

One of the things from my economist hat that I love about working here is just this front-row seat to, hey, what's the growth trajectory of each successive wave of startups in particular, and the current wave, of course, is AI. We work with AI companies across the stack. So when I talk about the AI companies on Stripe, you should think of this as everything from infrastructure and modeling to full-blown applications: OpenAI, Anthropic, Suno, Perplexity, Cognition, ElevenLabs, Decagon, Sierra, and a long tail of others.

We recently looked at the Forbes AI 50, and 78% of them are Stripe users. That 78% reflects 100% of the Forbes AI 50 that accept online payments. And I think there's a lot of hype around AI tech, and I think fair questions around the monetization. And so we took a look at, hey, with this current wave of AI startups, what do we see in their monetization trends and in their growth trajectories? The long and short of it is they are monetizing super fast.

They are monetizing faster than any previous generation of startups that we've seen. We focused in, just for concreteness, on the top 100 highest-grossing AI companies on Stripe, and we asked, okay, for the median in that cohort, how long did it take them to hit various revenue milestones, and what did their customer base look like? What did their monetization strategy look like? And those that already hit $30 million in annualized revenue got there in about a year and a half.

For comparison, many of us were around five years ago. The fastest-growing SaaS startups on Stripe took five and a half years to hit that same mark. So this kind of AI wave is scaling revenue at, you can think of, like 3x the speed of the SaaS boom. And it's not just the big players. If you look at the newest AI startups, the ones just getting going, they're ramping even faster. The ones that hit a million, the median gets there in five months.

They're earning 4x more in their first year than peers who launched just a couple years earlier. I was at Stripe Tour Paris a week and a half ago, and was looking at some of the European breakouts. Lovable out of Stockholm hit $50 million ARR in six months and is now for sure the fastest-growing startup in Europe. Cursor, which of course we mentioned earlier, helps developers code with AI. They only launched two years ago. They recently announced that they're over $300 million in ARR.

So, just really astounding growth rates. And I think it doesn't mean it comes without cost, including inference costs, but this is a real wave of businesses building real value in the market, else they wouldn't be able to monetize it. And they're doing that way faster than we've seen. You mentioned Paris and Europe.

For sure. These AI companies are going global way faster than their predecessors. If you look at that AI 100 group and you ask the median, the median is in 55 countries in their first year and 80 countries by their second year. And that is twice the internationalization of equally promising earlier SaaS companies at the same stage of their evolution. And it's real money that they're getting cross-border. Today, these companies generate the majority of their revenue. I think the median is 56% of revenues from international customers.

Back to France, like PhotoRoom, it's very cool. It's one of the darlings of France, the AI photo editor. It helps you clean up images. They went from, I think, $0 to $50 million ARR in three years. They already sell into 184 markets. I mean, you don't have to go that deep into your geography background to know there aren't that many more markets to sell into, right? And, well, some of it is that they're selling infrastructure and models and digital art and music and stuff that just works across borders.

Some of it is that LLMs are good at translation. But some of it, honestly, to our conversation earlier on Optimized Checkout Suite, is just that the bar to going global has gone down, right? So, almost all of these guys adopt our Optimized Checkout Suite. It comes with over 100 payment methods out of the box. That gives you global reach and conversion, but also, there's all the hassle of global managing tax and regulations, and a bunch of our solutions, like Stripe Tax, help these businesses scale up globally with very lean teams because that's another trend we didn't talk about yet. These folks are building very real businesses with, like, 10, 20, 30 people in a way that's quite striking and actually never been seen before.

So I have a hypothesis about a second-order effect from that, which I haven't robustly validated, but I'm going to say it anyway because I'd love for you to chew on it, which is an interesting corollary of being so global from day one is that today's vast internet markets enable and reward specialization. The markets today are so much bigger than they were a decade ago, and correspondingly, what people are building with AI is starting to look a lot like what we saw with SaaS: first horizontal and now vertical, right?

SaaS was like first Salesforce and then Toast. AI was like first broad tools like ChatGPT and then highly specialized industry-specific applications in healthcare, in real estate, in architecture, in restaurants. But the switch from horizontal to vertical, which definitely happened in SaaS, happened so much faster with AI. And I think part of that is for sure that the models enable these—we talked earlier about wrappers—these sort of specialized products to spin quickly and find product-market fit without having to sort of invest a bunch in upfront research.

But also, I think the fact that they are global provides additional tailwinds to that, which is when stuff is truly borderless, specialization is rewarded because the markets are bigger. And so even a very specialized niche is a very large business.

Okay, so selling software used to be: you build it once, you incur a fixed cost of building it once. I'm slightly oversimplifying. Obviously, you continue to do R&D, but it is a high fixed cost of building, and then you sell it by seat over and over and over again at very high margins because the marginal cost of providing the software is low. Okay. That is not true with AI. As products get more AI-centric, at least today, inference costs are more meaningful.

And so companies are shifting from this sort of per-seat billing. And by the way, if the AI does really well, there might also be fewer human users who need such seats. So it's not clear that per-seat billing was going to get you the revenue even if it worked, right? But companies are shifting to usage-based billing first to align pricing with costs. And then second, a trend—and this one's earlier, but I think it's where actually the market equilibrium, where clearing will actually happen two, three, five years from now—is experimenting with new pricing models like outcome-based pricing.

And actually increasingly using outcome-based pricing, which provides flexibility and really only charges you for the stuff that works, as a competitive differentiator. So, it can be hard to evaluate whether AI is going to work or not. And if you can go in and say, look, we're only going to charge you for what works, that is a much lower-risk proposition for the business than saying, we're going to charge you per seat, or we're going to charge you for usage, right? It's like, well, what if I use it, but it doesn't work well enough?

And so, I'm paying the inference cost, but it's not moving the needle for my business. And so, Intercom is an Irish-founded company, and they're also reinventing customer service. There's a lot of interesting stuff in the customer service space, but they're moving their support product from charging per seat, right, the olden-days model, which is how most SaaS is built, to charging per resolved case, which aligns incentives with their customers, and it is actually an outcome-based version of pricing. So I just think, stepping back, AI is changing everything.

It's increasing productivity, we think. You don't want a pricing model that is static. You don't want a pricing model that depends on your customers hiring ever more people. You also don't want a pricing model that is assuming near-zero marginal costs, given inference costs. And so we do see these businesses iterating very quickly to figure out where supply and demand intersect. And correspondingly, we're sort of arm in arm with them, working on our billing solutions, including usage-based billing and outcome-based billing, and really partnering with this current wave of AI startups to make sure that their pricing and monetization approaches, A, work for the market, and then B, can be very fast-evolving and highly unconstrained.

For us, I think it really starts with a culture of experimentation. And I actually like to tell the story of how, back, boy, like two years ago now, a couple of engineers hacked together a little internal beta for an LLM Explorer. And the basic idea was like, hey, let's get a ChatGPT-like interface in the hands of thousands of talented Stripe employees and just have them figure out how to apply it to their work. Stripe is coming into this from a long-running culture of bottoms-up experimentation, all the way up to Patrick and John.

Leaders here have very intentionally crafted that. We think a lot about sustaining experimentation and innovation internally as we grow. And so, in the case of LLMs, for us, this was like, hey, let's just quickly unlock internal experimentation. And obviously, that needs to be done safely, right? People are going to experiment. The enthusiasm was palpable. They better not be in their personal ChatGPT accounts, especially given the sensitivity of Stripe data. So, we decided fairly early on to organize cross-functionally and just set up the tools and policies so that any Striper could safely play with LLM capabilities.

We also decided early on to decouple from any one model because we saw the models evolving quickly. GPT-3.5 and GPT-4, but today we serve dozens of models through the tool. We enabled collaboration. People are very social, and the returns you get from building something are almost never worth it if that thing only works for you. And so, we enabled these things called presets, which are basically shareable prompts. And basically overnight, the Stripe community developed hundreds of these reusable LLM interaction patterns.

And I think from there we were kind of off to the races. We had a bunch more to do, like, hey, let's make sure that—well, so we built LLM Proxy. Any engineer should be able to hit a standard API to get access to LLMs and build their production-grade applications. We actually only relatively recently GA'd an agent builder internally that hooks up to what we call Toolshed, so it has access to the MCP servers for Google Cloud and Jira and Slack and whatever else.

But it started with just a small number of engineers saying everyone at Stripe should have access to LLMs. They should be able to share what they build with LLMs. Then they should be able to access those LLMs programmatically, and then they should be able to build agents on top.

It's a lot of going big on what we talked about today, like deploying our foundation model across applications, building really robust risk-as-a-service, helping our users prepare for commerce in an AI era. I can't share any super specifics, but I think you can kind of see where we're headed with foundation models, with MCP, with order intent, with the Perplexity shopping example. And you can expect to see more of that from us in the coming months.

Super. Thanks for having me, Matt.