I feel like the word "protocol", is just abused like it is a glorified marketing term. Kind of like how the word "hacker" was abused in everything else that had nothing to do with hacking.
MCP was just a glorified way of tool calling but generated so much hype (and it eventually died down). Now we have MPP. Which again - could have just been another tool call exposed to the agent.
Imagine you hire someone who claimed to have invented a new protocol and you're thinking of something like TCP or UDP, but all they share is just a markdown file.
Jokes about wallet-draining aside, we're already giving our agents a real cash budget that they use for tokens. Our harnesses have mechanisms to manage that spend. And having an easily detectable protocol would allow the harness to ensure that its deterministic code is in play to make these payments - you'd give your payment details to the harness, not to the agent itself.
And as to use cases, if I want quality outputs for automated research and discovery of a topic, in a world where quality journalism/scholarship should be compensated and does use tools like Cloudflare to block automated access, and where AI-generated content is everywhere, it's optimal for me to want to spend some amount of the money I spend on tokens, on the ability for my agent to access reputable primary and secondary sources as needed.
The challenge, of course, is that now there's an incentive for a spam source to try to get my agent to pay it, rather than the actual creator of the content. But there are interesting ways to solve this, because with these payment rails there's now an incentive for alliances of content creators to maintain indices of reputable sources and their canonical domains - perhaps even authoritative hashes of content. Lots of possibilities here.
> we're already giving our agents a real cash budget that they use for tokens.
I read this line and my (poor little) brain ran in a whole other direction for a moment. Because AI token management and "parental controls" aren't that far separated functionally.
How far are we from the AI companies selling token packs like video games sell premium currency? Buy NOW, 1.99 for 10,000 Anthropic gold...
You're absolutely right! I should have sent $5.00 for that transaction and not $500,000. I will generate a letter for you to print and sign and send to your bank to notify them of my mistake. Would you like me to generate a bankruptcy filing for you as well?
LLMs rarely admit fault, you gotta shift blame onto the user:
> You're absolutely right! The transaction was submitted as $500,000 instead of $5.00. Since that's what was entered on your end, you'll need to contact your bank to resolve it. I will generate a letter for you to print, sign, and send to your bank if needed. Would you like me to generate a bankruptcy filing for you as well?
There's a slightly new topic called Agentic Commerce, where you say for example: "purchase for me the most energy efficient dishwasher with a budget of $600", and the agent will connect via specialized via special MCP Servers and APIs to available stores, and will do the full purchase process for you.
This MPP helps bridge the gap between the agent putting the product "in the basket", to actually completing the full purchase process.
Disclaimer: I'm not in any way advocating for this use case, but it's part of my job to understand how it works. Part of what I do is try to help Agents understand, for example, what is "an efficient dishwasher" using actual data, and not hallucinated info.
I'm probably overlooking something, but what makes the problem of being able to get from item in basket to item is shipping different from choosing which item(s) to put in the basket?
In other words, if Agents are able to navigate marketplaces, shouldn't that imply they can also navigate a subset of the marketplace, the payment section? Especially given that that section is "easier: theres no need for qualitative (or quantitative) judgement like there is for the shopping portion.
It's not actually doing browser actions like Playwright or other browser automation tools, rather than direct API and MCP calls/actions. This is a whole new subset of API and connections that are all contained within the Agent context, no browser mocking. That's why they are creating these new protocols, so the full governance can work within the context of the Agent and its available tools.
As I said, it doesn't have to make sense, but this is being pushed on us anyway...
As much as I detest having to look at ads or being "influenced" in any way, shape or form, I think the opportunities for exploitation with what you just described is potentially orders of magnitude more harmful. Sure, let me just hand my wallet to a stochastic black box with god-knows-what RL'd biases and then hook it up to adversarial data sources all vying to extract the most money from me - what could possibly go wrong?
And would it not be useful to have some kind of human in the middle? For example what is to stop charge backs if no human has actually authorized the transaction?
the real question for me is what happens when agents start hitting premium data APIs with MPP. right now if i want my agent to pull realtime financial data it has to go through my API keys with monthly billing. with MPP the agent could theoretically pay per-query directly to data vendors. thats a much better model for bursty workloads but the authorization problem naomi_kynes raised is real - you need spending caps that the agent cant override, not just logging.
Hey, I'm one of the developers at Tempo. We're working on an extension type for subscriptions to propose being added to the spec as well! We're starting with the simple types, but subscriptions are a natural extension. The subscription intent will work similarly to a one-time charge—the server returns a 402 with intent="subscription", and the client signs a recurring authorization.
> MPP provides a specification for agents and services to coordinate payments programmatically, enabling microtransactions, *recurring payments*, and more.
I believe the Shared Payment Token is interchangeable with a payment method id that you attach to a customer object, but that link has very sparse information about how things actually work end to end and what objects mean what.
MPP handles 'how do agents pay', but not 'did anyone authorize this'. For low-value API calls that's fine. But once agents start chaining transactions, you need a channel where the agent can ask a human 'I'm about to spend $2k on this, still in scope?' before the payment happens - not a fraud alert after. The authorization layer is a separate infrastructure problem from the payment protocol.
I feel like the word "protocol", is just abused like it is a glorified marketing term. Kind of like how the word "hacker" was abused in everything else that had nothing to do with hacking.
MCP was just a glorified way of tool calling but generated so much hype (and it eventually died down). Now we have MPP. Which again - could have just been another tool call exposed to the agent.
Imagine you hire someone who claimed to have invented a new protocol and you're thinking of something like TCP or UDP, but all they share is just a markdown file.
The good ol' folks at Stripe's collaborators Tempo Labs tried to make an RFC-style description page for MPP: https://paymentauth.org/ (full doc on IETF draft page: https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment...)
I almost was going to point it out as evidence there was thought put into it. Nope, it's flimsy and AI generated.
Also, it contains provisions for scamming customers:
> 403 indicates the payment succeeded but access is denied by policy
No, it doesn't explain how to refund payments for customers you deny access to.
Jokes about wallet-draining aside, we're already giving our agents a real cash budget that they use for tokens. Our harnesses have mechanisms to manage that spend. And having an easily detectable protocol would allow the harness to ensure that its deterministic code is in play to make these payments - you'd give your payment details to the harness, not to the agent itself.
And as to use cases, if I want quality outputs for automated research and discovery of a topic, in a world where quality journalism/scholarship should be compensated and does use tools like Cloudflare to block automated access, and where AI-generated content is everywhere, it's optimal for me to want to spend some amount of the money I spend on tokens, on the ability for my agent to access reputable primary and secondary sources as needed.
The challenge, of course, is that now there's an incentive for a spam source to try to get my agent to pay it, rather than the actual creator of the content. But there are interesting ways to solve this, because with these payment rails there's now an incentive for alliances of content creators to maintain indices of reputable sources and their canonical domains - perhaps even authoritative hashes of content. Lots of possibilities here.
> we're already giving our agents a real cash budget that they use for tokens.
I read this line and my (poor little) brain ran in a whole other direction for a moment. Because AI token management and "parental controls" aren't that far separated functionally.
How far are we from the AI companies selling token packs like video games sell premium currency? Buy NOW, 1.99 for 10,000 Anthropic gold...
I fail to see how "API call" is anything inherent to Agents/LLMs?
Is this an attempt to get multiple payment processors to adopt the same Payments API so that agents fail less often?
It has nothing to do with Agents/LLMs which is why it's not called "Agentic Payment Protocol."
It's an API for making purchases instead of interacting with a website of unknown flow.
I guess competition with the Bitcoin equivalent https://www.l402.org/
And https://www.x402.org/
You're absolutely right! I should have sent $5.00 for that transaction and not $500,000. I will generate a letter for you to print and sign and send to your bank to notify them of my mistake. Would you like me to generate a bankruptcy filing for you as well?
LLMs rarely admit fault, you gotta shift blame onto the user:
> You're absolutely right! The transaction was submitted as $500,000 instead of $5.00. Since that's what was entered on your end, you'll need to contact your bank to resolve it. I will generate a letter for you to print, sign, and send to your bank if needed. Would you like me to generate a bankruptcy filing for you as well?
Fascinating — this is the future of decentralized finance. Agents will be the entities that both earn and consume.
Maybe. When it comes to actual payments, fee structures don't allow for this outside of the laboratory.
What does this actually have to do with agents? What does the protocol include that makes this useful with AI rather than just a boring old program?
That's why it's called Machine Payments Protocol, instead of Agent Payments Protocol
There's a slightly new topic called Agentic Commerce, where you say for example: "purchase for me the most energy efficient dishwasher with a budget of $600", and the agent will connect via specialized via special MCP Servers and APIs to available stores, and will do the full purchase process for you.
This MPP helps bridge the gap between the agent putting the product "in the basket", to actually completing the full purchase process.
Disclaimer: I'm not in any way advocating for this use case, but it's part of my job to understand how it works. Part of what I do is try to help Agents understand, for example, what is "an efficient dishwasher" using actual data, and not hallucinated info.
I'm probably overlooking something, but what makes the problem of being able to get from item in basket to item is shipping different from choosing which item(s) to put in the basket?
In other words, if Agents are able to navigate marketplaces, shouldn't that imply they can also navigate a subset of the marketplace, the payment section? Especially given that that section is "easier: theres no need for qualitative (or quantitative) judgement like there is for the shopping portion.
Perhaps its a matter of proper safeguards?
It's not actually doing browser actions like Playwright or other browser automation tools, rather than direct API and MCP calls/actions. This is a whole new subset of API and connections that are all contained within the Agent context, no browser mocking. That's why they are creating these new protocols, so the full governance can work within the context of the Agent and its available tools.
As I said, it doesn't have to make sense, but this is being pushed on us anyway...
As much as I detest having to look at ads or being "influenced" in any way, shape or form, I think the opportunities for exploitation with what you just described is potentially orders of magnitude more harmful. Sure, let me just hand my wallet to a stochastic black box with god-knows-what RL'd biases and then hook it up to adversarial data sources all vying to extract the most money from me - what could possibly go wrong?
And would it not be useful to have some kind of human in the middle? For example what is to stop charge backs if no human has actually authorized the transaction?
Didn't stripe already have a payments protocol?
MPP's supposed to eventually work with more than Stripe.
the real question for me is what happens when agents start hitting premium data APIs with MPP. right now if i want my agent to pull realtime financial data it has to go through my API keys with monthly billing. with MPP the agent could theoretically pay per-query directly to data vendors. thats a much better model for bursty workloads but the authorization problem naomi_kynes raised is real - you need spending caps that the agent cant override, not just logging.
It seems like this is designed for atomic purchases, could it be extended for subscriptions?
Hey, I'm one of the developers at Tempo. We're working on an extension type for subscriptions to propose being added to the spec as well! We're starting with the simple types, but subscriptions are a natural extension. The subscription intent will work similarly to a one-time charge—the server returns a 402 with intent="subscription", and the client signs a recurring authorization.
> MPP provides a specification for agents and services to coordinate payments programmatically, enabling microtransactions, *recurring payments*, and more.
https://docs.stripe.com/payments/machine/mpp
Yeah I read that copy too, did you read the spec?
I believe the Shared Payment Token is interchangeable with a payment method id that you attach to a customer object, but that link has very sparse information about how things actually work end to end and what objects mean what.
This is a good standard that I can get behind [0] since it's a serious proposal and submitted to the IETF [1] for MPP for machine-to-machine payments.
A well thought out proposal for the long term, unlike MCP which is a complete joke of a "standard" and broken by design.
[0] https://paymentauth.org/
[1] https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment...
Curious since I haven't followed super closely: what's busted about MCP?
MPP handles 'how do agents pay', but not 'did anyone authorize this'. For low-value API calls that's fine. But once agents start chaining transactions, you need a channel where the agent can ask a human 'I'm about to spend $2k on this, still in scope?' before the payment happens - not a fraud alert after. The authorization layer is a separate infrastructure problem from the payment protocol.